This commit reimplements the (no longer recommended) setuptools based
build system using a standards-based in-tree PEP517 build backend.
The implementation is partially based on
https://codeberg.org/ziglang/zig-pypi/src/branch/main/make_wheels.py
which is licensed under BSD-0-clause.
It also adds a new option `YOSYS_BUILD_PYTHON_ONLY` that is available
only if the binary or the library aren't going to be installed, which
turns off these targets entirely, as well as some dependent ones
(e.g. tests).
Co-authored-by: Mohamed Gaber <me@donn.website>
This make sure the method work also when the program is located in
deep or long file paths, longer than both PATH_MAX and "getconf
PATH_MAX .". Use the same code on GNU Hurd, where it now work.
I am not sure how to test this in a platform independent way.
We could make it safe to increment autoidx during multithreaded passes, but that's
actually undesirable because it would lead to nondeterminism. If/when we need new
IDs during parallel passes, we'll have to figure out how to allocate them in a
deterministic way, and that will depend on the details of what the pass does.
So don't try to tackle that now.
For consistency.
Also trying a new thing: only rebuilding objects that use the pybind11 library. The idea is these are the only objects that include the Python/pybind headers and thus the only ones that depend on the Python ABI in any capacity, so other objects can be reused across wheel builds. This has the potential to cut down build times.
- Rewrite all Python features to use the pybind11 library instead of boost::python.
Unlike boost::python, pybind11 is a header-only library that is just included by Pyosys code, saving a lot of compile time on wheels.
- Factor out as much "translation" code from the generator into proper C++ files
- Fix running the embedded interpreter not supporting "from pyosys import libyosys as ys" like wheels
- Move Python-related elements to `pyosys` directory at the root of the repo
- Slight shift in bridging semantics:
- Containers are declared as "opaque types" and are passed by reference to Python - many methods have been implemented to make them feel right at home without the overhead/ambiguity of copying to Python and then copying back after mutation
- Monitor/Pass use "trampoline" pattern to support virual methods overridable in Python: virtual methods no longer require `py_` prefix
- Create really short test set for pyosys that just exercises basic functionality
Large circuits can run hundreds or thousands of ABCs in a single AbcPass.
For some circuits, some of those ABC runs can run for hundreds of seconds.
Running ABCs in parallel with each other and in parallel with main-thread
processing (reading and writing BLIF files, copying ABC BLIF output into
the design) can give large speedups.
