GNU bug report logs - #78233
[PATCH 0/2 electronics-team] Upgrade nextpnr.

Previous Next

Full log

Message #38 received at 78233 <at> debbugs.gnu.org (full text, mbox):

From: Cayetano Santos <csantosb <at> inventati.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 78233 <at> debbugs.gnu.org, Gabriel Wicki <gabriel <at> erlikon.ch>,
 Ekaitz Zarraga <ekaitz <at> elenq.tech>
Subject: Re: [bug#78233] [PATCH 1/2] gnu: Add nextpnr.
Date: Sun, 11 May 2025 19:31:42 +0200

[Message part 1 (text/plain, inline)]

>dim. 11 mai 2025 at 22:14, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:

> Hi,
>
> Cayetano Santos <csantosb <at> inventati.org> writes:
>
>>>jeu. 08 mai 2025 at 21:43, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> 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.

Ok , I understand now. Upstream, they’re half way towards supporting
system libraries, instead of built-in. I’ll send them a PR to consider
the remaining libraries we need, so that next time we will simply this
package.

C.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.