>lun. 12 mai 2025 at 20:54, Maxim Cournoyer wrote: > Hi Cayetano, > > Cayetano Santos writes: > >>>lun. 12 mai 2025 at 16:14, Maxim Cournoyer wrote: >> >>> Thanks for V2, I've used it as the base of nextpnr-ice40 package, for >>> which I've also added patches, as mentioned previously. >> >> Thanks a lot for this ! I’m sure that providing a whole pipeline for fpga >> development (yosys+nextpnr+fpgaloader) in Guix is a rewarding effort. >> >>> By first updating nextpnr-ice40 to v0.8 and related changes, and later >>> renaming it to nextpnr with few adjustments needed, the commit history >>> is as clear as it can be. Please have a look/test to make sure >>> everything still works as intended. >> >> Well, I’m afraid I was not clear enough about it, but the whole original idea >> was to get a different package per device: >> >> - nextpnr (not public) :: generic package >> - nextpnr-ice40 (public, inherits from nextpnr) :: icestorm backend >> - nextpnr-ecp5 (public, inherits from nextpnr) :: prjtrellis backend >> - nextpnr-generic (public, inherits from nextpnr) :: no backend >> - nextpnr-himbaechel-gowin (public, inherits from nextpnr) :: >> - nextpnr-himbaechel-ng-ultra (public, inherits from nextpnr) :: >> prjbeyond-db backend >> - nextpnr-nexus :: ... >> - etc. >> >> You can see the overall concept in my testing playground [0]. > > I see. That's neat, but I think I'd rather try a single 'nextpnr' > package that does it all first, and complicate later if we find it > becomes unpractical. The benefits: > > 1. all the executables share the same library, so space and compute > wise, it makes sense they are packaged together. > > 2. There doesn't seem to be many different inputs to be added to build > all the backends, so the maintenance cost should similar. Inheritance > also introduce some complexity, by having to keep everything in sync > while the Guix tooling doesn't make the relationship easy to discover > (via 'guix refresh --list-transitive say'). > > 3. It's done elsewhere, e.g. in nixpkgs, so we can compare in case of > problems. > > What do you think? Fine with me; just keep in mind that we are not testing the binaries (nextpnr-himbaechel, etc.). This is it: #78390. It builds and performs as expected in all 4 architectures. C.