Subject: [bug#27344] [PATCH v3 2/8] gnu: Add libngspice and ngspice.

From: Theodoros Foradis <[email-masked]>
Date: Fri, 29 Sep 2017 00:24:13 +0300

Ludovic Courtès writes:

> Theodoros Foradis <[email-masked]> 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.

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?

I'm not sure what the "guix" way of handling this is.

WDYT?
-- 
Theodoros Foradis