Subject: [bug#78233] [PATCH 2/2] gnu: nextpnr-ice40: Update to 0.8.

From: Cayetano Santos <[email-masked]>
Date: Mon, 12 May 2025 14:24:05 +0200

>lun. 12 mai 2025 at 20:54, Maxim Cournoyer <[email-masked]> wrote:

> Hi Cayetano,
>
> Cayetano Santos <[email-masked]> writes:
>
>>>lun. 12 mai 2025 at 16:14, Maxim Cournoyer <[email-masked]> 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.