[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inputs vs. native-inputs vs. propagated-inputs
From: |
Hartmut Goebel |
Subject: |
Re: inputs vs. native-inputs vs. propagated-inputs |
Date: |
Sun, 12 Jun 2016 17:50:29 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
Hi,
Thanks for your answer
Am 12.06.2016 um 14:38 schrieb 宋文武:
> Hartmut Goebel <address@hidden> 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."
>
>> 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?
> By looking the output of ‘guix gc –-references …’, the build time ones
> are ones not there.
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.
>
>> Same for pkg-config: How to determine if this is only needed ar build
>> time (as I would always expect)? The manual says:
>>
>> … propagated-inputs …
>> For example this is necessary when a C/C++ library needs
>> headers of another library to compile, or when a pkg-config
>> file refers to another one via its ‘Requires’ field.
>>
>> For me this is confusing.
> Many build systems use ‘pkg-config’ to check for libraries and get
> flags, a pc file usually list some other packages in its ‘Requires’
> field, if one of these packages is missing (doesn’t have a <package>.pc
> file in PKG_CONFIG_PATH), this pc file will be treated as broken, and
> the package will be reported as ‘not found’. So propageted these
> packages make ‘pkg-config’ works, reduce the work for packaging its
> users (otherwise, those packages need to added as inputs even they’re
> not used directly).
Thanks, I misunderstood the example. I though it was talking about
"pkg-config", while it is talking about .pc files.
--
Regards
Hartmut Goebel
| Hartmut Goebel | address@hidden |
| www.crazy-compilers.com | compilers which you thought are impossible |
- 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 <=
- 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, 2016/06/17
- 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