Subject: Re: [bug#78233] [PATCH 1/2] gnu: Add nextpnr.

From: Maxim Cournoyer <[email-masked]>
Date: Sun, 11 May 2025 22:14:43 +0900

Hi,

Cayetano Santos <[email-masked]> writes:

>>jeu. 08 mai 2025 at 21:43, Maxim Cournoyer <[email-masked]> wrote:
>
>> Why do we not build the GUI?  We already have the Qt dependencies, it
>> seems.
>
> Simply, I’m  unable to compile 0.8 with the gui flag on.
>
> To me, the priority now is providing in Guix a place and route workflow
> for all available nextpnr backends in cli mode, which is what most
> engineers use. In a second time, we will investigate how to build the
> gui and how activate other interesting options, but I’d rather prefer
> this point not to be a big stopper to what really matters.

>> Well done!  If the source changes often, a patch could be more
>> maintainable; ideally in way that can be forwarded upstream too, with
>> good chances of being merged.  That's less work for us in the long term.

I think my comments were w.r.t. to patching the build system to use
system-provided libraries.  Patching commands to use the Guix-specific
file names should remain as they are as substitutions in phases.

> Generally speaking, I see what you mean. In this very case, I don’t
> understand how to replace current invocations to inputs
> (this-package-input) with a patch; neither I see how upstream might
> consider a patch to Guix only requirements, specially, as there is no
> support to compilations not using the 3rd party modules they provide.

That would mean contributing newly authored CMake glue code that would
make configuring using system-provided libraries possible.  It's more
work, but worth it in the long term.  I agree this doesn't need to block
the current submission.

-- 
Thanks,
Maxim