Re: Rethinking propagated inputs?

[Ludovic Courtès]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> Am Donnerstag, den 09.09.2021, 00:12 +0200 schrieb Ludovic Courtès:

[...]

>> It would be great if the ‘Requires’ field of .pc files could specify
>> absolute file name; it would no longer be necessary to set
>> PKG_CONFIG_PATH, and thus propagation wouldn’t be needed in this
>> case.
> In that regard, would symlinking other pkg-config files as proposed
> somewhere in passing in [1] also work?  We would have to add a phase,
> that parses the Requires field from installed pkg-config files, and
> then symlinks the respective files from the inputs to gnu-build-system, 
> but since they would then exist in PKG_CONFIG_PATH and point to the
> library in question, theoretically we could get around this limitation
> of pkg-config without requiring propagation.

Why not, that could work.

>> Regarding outputs, Nixpkgs introduced a “dev” output a while back
>> that lumps together our “lib” and “include” outputs, roughly.  I
>> think that’s a good idea (for other reasons too).
> Naming-wise I'd still prefer the more concrete “lib” as “dev” to me is
> a weird umbrella term that doesn't really tell me what I'm getting
> (also it probably contributes to the distinction of users and devs, and
> as some distros like Debian have demonstrated often becomes
> pointless[2] the minute you introduce language bindings which require
> dev inputs anyway).  
>
> As far as the lib/include split in Guix is concerned, there appear to
> be few packages that split them, so “lib” effectively is “dev” in Guix
> when “out” isn't.  So apart from those outliers, is there something our
> “lib” outputs are missing that Nix' “dev” outputs include?

We’d have to check how they do it in Nix.  Basically, it’s about
reversing things: currently, everything goes to “out”, and a tiny bit
goes to “lib”.  Here, it’d be the other way around: “out” would contain
only binaries and doc (unless there’s a “doc” output), and “dev” would
contain everything else (headers, pkg-config files, cmake files, section
3 man pages, etc.)

It needs more thought and it may be hard to get right, but hopefully we
can learn from Nixpkgs here.

Now, IIRC, the Nixpkgs folks found that it didn’t have a significant
impact on closure size, contrary to what they had hoped for.  That too
needs to be taken into account.

Ludo’.