[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26170: Bug #26170 Hunting: doc: Explanation of propagated-inputs unc
From: |
Ludovic Courtès |
Subject: |
bug#26170: Bug #26170 Hunting: doc: Explanation of propagated-inputs unclear |
Date: |
Thu, 17 Sep 2020 21:45:09 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi,
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> On Wed, Sep 16, 2020 at 12:37:20PM +0200, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
>> > Another example where @code{propagated-inputs} is useful is for languages
>> > that lack a facility to record the run-time search path akin to the
>> > @code{RUNPATH} of ELF files; this includes Guile, Python, Perl, and
>> > -more. To ensure that libraries written in those languages can find
>> > -library code they depend on at run time, run-time dependencies must be
>> > -listed in @code{propagated-inputs} rather than @code{inputs}.
>> > +more. When packaging libraries written in those languages, ensure they
>> > can find
>> > +library code they depend on at run time by listing run-time dependencies
>> > +in @code{propagated-inputs} rather than @code{inputs}.
>>
>> I’m not convinced about this hunk; it uses imperative tense towards the
>> reader to state the same thing no?
>
> The difference is “When packaging libraries”. I suppose the intention
> is that propagated-inputs be declared as part of library packages and
> not as part of the application using those libraries. I am unsure if
> I understand correctly if “When packaging libraries” is not explicitly
> stated.
Oh I see, that makes sense to me. Go ahead! :-)
Thanks,
Ludo’.