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

[Leo Famulari <leo@famulari.name>]

On Fri, Jun 17, 2016 at 10:49:59PM +0200, Hartmut Goebel wrote:
> >>> 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.
> 
> IC. I was hoping. I could just package some stuff without any knowledge.
> E.g  to make basic libraries and programs available so others can add
> more programs. Obviously I was wrong here :-(

To clarify: it does not require expert knowledge. If the upstream
maintainers have used a standard build system like Python's setuptools
or Automake, packaging for Guix is almost as easy as filling out a form.

> > Also, once you've built the package, using `guix gc --references` is a
> > good way to inspect it. 
> 
> This is what I do not get: If I do not specify some dependency, how will
> it be listed with `gc --references` (except the case there is another
> dependency). And if `gc --references` would be able to find dependencies
> I missed, why at all should one list dependencies?

`gc --references` is a diagnostic tool that looks at the result of
building the package, and reports what it finds. It's up to us to decide
if the result is what we expected.

I _think_ that `gc --references` works by querying the database for a
list of references in the store item you give it as an argument. I think
that the information in the database is created after building, by
scanning the files of the package's output in /gnu/store, looking for
strings that appear to be paths in /gnu/store. I say "I think" because I
am not sure. I don't understand that part of the code very well yet.

Here's an example of how I use it:
http://lists.gnu.org/archive/html/guix-devel/2016-06/msg00367.html

That package, msgpack, requires zlib to build and run.  After adding
zlib to msgpack's inputs, msgpack's build system is able to find zlib
and build msgpack successfully.

But, I used `guix gc --references` to list the references in
'/gnu/store/...-msgpack' to other store items, and there are no
references to zlib. That is, there are no strings in the msgpack output
that are paths like '/gnu/store/...-zlib'.

For some reason, the build process is not recording the location of zlib
into the built msgpack binaries. So, msgpack will probably not work
until we fix that.

I hope this helps.