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.
17943a51cb