moss: refactor build script add ability to configure backends

[jleightcap]

(In response to ngi-nix/ngipkgs#7 (comment))

We started by refactoring the builder = ... attribute of the nextpnr-xilinx-chipdb derivation. This builder script had the neccessary build logic for interacting with the prjxray-db, but had some glue logic for interacting with the external dependencies.

We refactored this to be inline shell script in the derivation definition, porting over the build logic.
We left a note about future work splitting out the installPhase.

We took a look at your comment,

Also, I would like to call the builder with different arguments to create different flakes with the different FPGA families (artiz7, kintex7, spartan7 zynq7). What would be the best way to go about it?
I also would like to make those optional. How would I want to do that?

Our thought was to have a 'base' derivation for nextpnr-xilinx-chipdb, then configure the backend based on overrides. Ideally, the building process looks like

nix build .#nextpnr-xilinx-chipdb.zynq7 # only includes zynq7
# ...

Let us know if that's along the lines you were thinking @hansfbaier!

[hansfbaier]

@jleightcap I tried it, but since the overrides are commented out, it only seems to build the default zynq7, no matter what backent I try to build.

[hansfbaier]

I tried this:

But still the same result.

[jleightcap]

We ended a working session trying to understand why overrideAttrs fails to override the backend key inside the base _nextpnr-xilinx-chipdb derivation -- like you mention the "default" value of "zynq7" is passed regardless. Overriding within an overlay was not something we were familiar with, we'll pick it back up at an upcoming mob 🙂

[jleightcap]

We got the backend selection working in 5e94912 using callPackage. This pattern has a 'meta-package' for the chip-db, that takes a backend argument. This was the cleanest solution we came up with, let us know if it makes sense.

Waiting for the DB to build to verify the outputs, but the buildPhase is a straight-foward adaption of the existing builder script.

[jleightcap]

Invocations:

$ nix build .#nextpnr-xilinx-chipdb.kintex7
# builds with only one backend, etc.

[hansfbaier]

@jleightcap That works, many thanks!

[hansfbaier]

@jleightcap That leaves the question, how can I query the path to the chipdb output for a specific backend?
I did it like this:
nix eval --raw '.#packages.x86_64-linux.nextpnr-xilinx-chipdb.spartan7.outPath'
Is there a more elegant method?
Actually I think the chipdb files might not be architecture specific (except endianness maybe)

[jleightcap]

Slightly more elegant, maybe, is:

$ nix eval --raw ".#nextpn-xilinx-chipdb.spartan7.outPath"

Like you said, this includes the implicit architecture prefix of the host (packages.x86_64-linux.).

Unless you mean how to query the output path prior to building the package? As far as I know that hash embedded in the path is derived from the output and so can't be computed without fully evaluating the package.

Let me know if that makes sense!

[hansfbaier]

@jleightcap That is perfect, thanks!