>dim. 11 mai 2025 at 22:14, Maxim Cournoyer wrote: > Hi, > > Cayetano Santos writes: > >>>jeu. 08 mai 2025 at 21:43, Maxim Cournoyer 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.