Re: inputs vs. native-inputs vs. propagated-inputs

[Leo Famulari <leo@famulari.name>]

On Sun, Jun 12, 2016 at 05:50:29PM +0200, Hartmut Goebel wrote:
> Am 12.06.2016 um 14:38 schrieb 宋文武:
> > Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
> >> For for I understand. But then the manual says:
> >>
> >>           ‘native-inputs’ is typically used to list tools needed at
> >>           build time, but not at run time, such as Autoconf, Automake,
> >>           pkg-config, Gettext, or Bison.
> >>
> >> The first sentence implies that "inputs" are treated as needed at run
> >> time.
> > No, as _native_ inputs usually are tools for building (and testing),
> > most time they’re not needed at run time.
> 
> This paragraph is only talking about "native-inputs" and about "needed …
> not at run time". While the paragraph just above this sentence is
> talking about both "inputs" and native-inputs", this "needed … not at
> run time" implies "inputs" are needed at run time.
> 
> I suggest rephrasing this into something like: "Both inputs and
> native-inputs are used for stuff needed at build time, not at run time.
> 'inputs' are for ..., e.g. library headers, ..., while 'native-inputs'
> are for tools such as Autoconf, Automake, pkg-config, Gettext, or Bison."

'Inputs' do typically get used at run-time, as do propagated-inputs.

I found it hard to understand the distinctions by reading. It was only
when I had been making packages for a while that I understood.

I've tried to improve this text but I haven't come up with anything yet.

> >> If so, how can I as a packager find out if eg. libBBB is only used at
> >> build time and libCCC need to be a propagated input?

You will need at least a little knowledge about the programs you are
packaging and how they are supposed to build and run. I read a bit about
each program to guess about how libAAA uses it.

> I'm the packager, so I'm the one who needs to *define* the dependencies.
> There is no ‘guix gc –-references …’ I can query. So *I* need a way to
> determine whether an input needs to be propagated or not.

Test the program in an isolated environment and see if it works without
propagating the inputs.

You can set up an environment with only libAAA ...

$ guix environment --container --ad-hoc libAAA

... and then somehow exercise libAAA to see if it can find its
dependencies.

Also, once you've built the package, using `guix gc --references` is a
good way to inspect it. 

The type of input chosen by the packager does not dictate how libAAA
uses the dependency. The package could erroneously retain a reference to
a native-input like Automake, and `guix gc --references` will show you
this.

So, if libCCC appears in `guix gc --references /gnu/store/...-libAAA`,
it's reasonable to guess that libCCC does not need to be propagated.

Or, the package could lack a reference to something you *know* is needed
at run-time. So you can address that with propagated-inputs or setting
some build-time configuration.

Is it making more sense?