Hello, Theodoros Foradis skribis: > Ludovic Courtès writes: > >> Theodoros Foradis skribis: >> >>> * gnu/packages/engineering.scm (libngspice): New variable. >>> * gnu/packages/engineering.scm (ngspice): New variable. >> >> I’m sorry for asking this late in the game, but I didn’t find the >> answer in previous discussions: why two packages? It seems to me that a >> “lib” output would achieve the same, no? >> >> (It’s best to leave a comment in such a situation.) >> >> If you tell me I’m wrong, that’s OK, I’ll apply it right away! > > The way this package's build system is set up, you cannot build both the > libraries and executables in the same run. That is, you need to run > ./configure (with the library-specific flag), make, then ./configure and > make again, to build everything. OK, that makes a lot of sense. > This is why I split the package in two. Initially (in v1 and v2 patch > series), I had libngspice be a non-public package, and ngspice was > copying the library to its normal output. > > After Danny's additions, different phases were added to both > packages, and unneeded files are deleted from their outputs. So, both > were made public, with only the minimal files needed for each > functionality. > > Would it be preferable to have libngspice as a non-public package again, > and have ngspice copy it to a "lib" output? Given that we’re dealing with a limitation of upstream’s build system, I think it’s OK to do it the way you did. I’ve committed the patch with the cosmetic changes below. Thanks, and sorry again for the delay! Ludo’.