This is useful for certain cross-compilation workloads, and to cache
rarely changing build products.
To use this functionality, build e.g. as follows:
cmake . -B build-export -DEXPORT_BBA_FILES=../bba-files -DARCH=all
cmake --build build-export -t nextpnr-all-bba
cmake . -B build-import -DIMPORT_BBA_FILES=../bba-files -DARCH=all
cmake --build build-import
The impetus for this commit is the fact that it causes rare but
build-breaking race conditions when used with `make -jN` with `N > 1`.
These race conditions are difficult to track down or fix because of
the very rudmentary debugging tools provided by `make` and opaque
semantics of CMake's Makefile generator. They break the build by
running two `.bba` generation processes, then one of them renaming
the `.bba.new` file once it's done, leaving the other one to fail.
After reflection (as the author of this code path) and discussion with
community members who use it, I've concluded that this isn't the right
approach.
1. In practice, on targets where `-DSERIALIZE_CHIPDBS=` matters, you
also care about other build steps, like linking nextpnr, which
are not serializable this way. So you use a workaround anyway, like
`make`ing individual targets instead.
2. The way to serialize the build with Make is the `-j1` option. Trying
to work around `-jN` to make it work like `-j1` is inherently error
prone. While there is some utility in not serializing C++ compilation
this utility could be more easily achieved by providing a single
target that builds all chipdbs, running `make <chipdb-target> -j1`,
then running `make -jN` for the rest of the build.
Two user-visible changes were made:
* `-DUSE_RUST` is replaced with `-DBUILD_RUST`, by analogy with
`-DBUILD_PYTHON`
* `-DCOVERAGE` was removed as it doesn't work with either modern GCC
or Clang
This removes the atomic rename for bbasm outputs because it embeds
the resulting paths into the `.cc` files in embed mode. In any case
the write should be fast enough to not be a big risk for interrupted
builds.
This was tested with Clang 19 only (gcc hasn't had a release that
supports `#embed` yet).
Primarily, this commit makes both of them use the `BBAsm` functions
to build and compile `.bba` files.
In addition, Himbaechel targets are now aligned with the rest in
how they are configured: instead of having all uarches enabled with
all of the devices disabled (the opposite of the rest of nextpnr),
uarches must be enabled explicitly but they come with all devices
enabled (except for Xilinx, which does not have a list of devices).
While it served a purpose (granting the ability to build `.bba` files
separately from the rest of nextpnr), it made things excessively
convoluted, especially around paths.
This commit removes the ability to pre-generate chip databases. As far
as I know, I was the primary user of that feature. It can be added back
if there is demand for it.
In exchange the per-family `CMakeLists.txt` files are now much easier
to understand.
