[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inputs vs. native-inputs vs. propagated-inputs
From: |
Leo Famulari |
Subject: |
Re: inputs vs. native-inputs vs. propagated-inputs |
Date: |
Fri, 17 Jun 2016 19:34:33 -0400 |
User-agent: |
Mutt/1.6.0 (2016-04-01) |
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.
- inputs vs. native-inputs vs. propagated-inputs, Hartmut Goebel, 2016/06/12
- Re: inputs vs. native-inputs vs. propagated-inputs, 宋文武, 2016/06/12
- Re: inputs vs. native-inputs vs. propagated-inputs, Hartmut Goebel, 2016/06/12
- Re: inputs vs. native-inputs vs. propagated-inputs, Leo Famulari, 2016/06/12
- Re: inputs vs. native-inputs vs. propagated-inputs, Hartmut Goebel, 2016/06/17
- Re: inputs vs. native-inputs vs. propagated-inputs,
Leo Famulari <=
- Re: inputs vs. native-inputs vs. propagated-inputs, Ludovic Courtès, 2016/06/18
- Re: inputs vs. native-inputs vs. propagated-inputs, Lukas Gradl, 2016/06/19
- Re: inputs vs. native-inputs vs. propagated-inputs, Ludovic Courtès, 2016/06/19
- Re: inputs vs. native-inputs vs. propagated-inputs, Lukas Gradl, 2016/06/21