native-propagated-inputs

native-propagated-inputs

[David Craven]

Hi guix,

Currently we use propagated inputs to specify propagated compile time
dependencies when they are needed by the header files or pkg-config
files or when they are needed at runtime. In addition we have the
mechanism of wrap-program to avoid having runtime dependencies being
propagated so that the dependency specification remains complete.
Wrap-program is also used for setting search paths for plugins.

The problem with wrap-program is that it makes debugging much harder
and doesn't work with the inbuilt gnu-build-system debugging support
that is enabled by adding "debug" to the list of outputs. It does not
find the debug symbols because the binary is called
binary.real-binary.

Instead of relying on wrap-program in these common cases, I think that
separating propagated-inputs in to native-propagated-inputs and
propagated-inputs may be a better way of solving this problem. We
already have native-inputs and inputs and native-search-path and
search-path so it seems to be like a natural extension.

Thoughts?

Re: native-propagated-inputs

[David Craven]

> Thoughts?

Actually it's a bad idea because it changes the semantics of native to
mean compile-time instead of the current semantics which means native
=P

Re: native-propagated-inputs

[Ludovic Courtès]

David Craven <david@craven.ch> skribis:

>> Thoughts?
>
> Actually it's a bad idea because it changes the semantics of native to
> mean compile-time instead of the current semantics which means native
> =P

Exactly.  :-)

Ludo’.