Re: Rethinking propagated inputs?

[Ludovic Courtès]

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> For packages using pkg-config, I had the following scheme in mind:

As a reminder to everyone, pkg-config is just one of the reasons for
propagating inputs, probably not the main one numerically speaking.

> A package that has .pc files puts them into a separate "build" output.
> The code handling 'propagated-inputs' is modified such that an entry in
> 'propagated-inputs' can have an additional 'propagated-for-output' component.
>
> (Feel free to suggest a more concise name.)
>
> I.e., something like:
>
>   (define glib
>     (package
>       (name "glib")
>       (outputs '("out" ; everything
>                  "bin" ; glib-mkenums ... depends on Python
>                  "build")) ; glib-2.0.pc
>       (propagated-inputs
>         `(("pcre" ,pcre #:propagate-for-output "build") ; in the 
> Requires.private field of glib-2.0.pc
>           ("libffi" ,libffi #:propagate-for-output "build") ; ditto, for 
> gobject-2.0.pc
>           ;; etc.
>           ))
>       (native-inputs '()) ; not relevant to this e-ail
>       ...))

Good’ol ‘ROADMAP’ file has a half-baked proposal along these lines.
It’s interesting, but I’m a bit concerned about the maintenance
cost/benefit ratio of this approach.  (It also goes against work on
simplifying the surface syntax of inputs.)

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.

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).

Ludo’.