Hi, I'm still a bit unhappy with the nextpnr package.
The package includes a pre-built database, which is endian-sensitive.For now, this means that the database packages are arch:any, and need to be built on each architecture, which is a bit tricky for 32 bit architectures (there is a Python script that consumes about 5 GB of RAM), although i386 somehow manages, takes a lot of time and requires some trickery to choose the appropriate amount of parallelism for the build.
So I have a bunch of horrible ideas: -> build big and little endian database packages that are arch:all.This is easy enough to do, and adjusting the dependencies of the binary packages is also doable.
However, the included unit tests depend on these databases being available, which leaves two options:
-> declare Build-Depends-Arch on the database.This should work for Debian, because arch:all is a separate autobuilder, but it feels kind of unclean.
It is also difficult to declare a dependency on the correct endianness of the package, unless I also
-> make the packages co-installable (changing internal paths), and depend on both.
Making them co-installable is probably a good idea either way.I'd also need a mechanism to allow building all binary packages at the same time, obviously that should not depend on the prebuilt database.
-> Build-Depends-Arch: prebuilt-database | database-sources Build-Depends-Indep: database-sourcesThis feels like I should find out if the target invoked was "build" or "build-arch", and, depending on that, decide whether to build databases or just use them. That doesn't feel clean at all either.
-> Alternatively, I could ship unit tests as a package, run through CI.This pollutes the package namespace, and reduces test coverage to architectures covered by CI.
Either of these also means that we no longer test whether the package can be completely built on all architectures, but I suppose that is minor.
Opinions? Simon
OpenPGP_signature.asc
Description: OpenPGP digital signature
