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

[Hartmut Goebel <h.goebel@crazy-compilers.com>]

Hi,

Thanks for your answer

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."


>
>> 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          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |