[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkg-config "Requires" fields and propagated inputs
From: |
Ludovic Courtès |
Subject: |
Re: pkg-config "Requires" fields and propagated inputs |
Date: |
Tue, 24 Mar 2015 21:57:17 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
address@hidden (Taylan Ulrich "Bayırlı/Kammer") skribis:
> If I'm reading pkg-config documentation[0] right, Requires are full
> run-time dependencies, meaning if a program uses libfoo which Requires
> libbar, the program will also want/have to use libbar's interface; OTOH
> Requires.private are "link-time" dependencies, i.e. libfoo dynamically
> links to libbar, so libbar needs to exist on the system at run-time, but
> a program using libfoo needn't use libbar's interface.
My reading of pkg-config(1) is that Requires.private is taken into
account only for ‘pkg-config foo --static --cflags/--libs’:
Requires.private:
A list of packages required by this package. The difference
from Requires is that the packages listed under
Requires.private are not taken into account when a flag list
is computed for dynamically linked executable (i.e., when
--static was not specified).
This is analogous to Libs.private in that regard.
In practice, we usually only care about shared libraries, thus...
> This would mean that Requires should be propagated inputs, and
> Requires.private only normal inputs;
... is mostly correct. “Mostly,” because it might be that, unless
--static is passed, things in Requires.private don’t even need to be
present.
Do you have an example of a package that uses Requires.private?
> However, pkg-config isn't aware of compile-time/run-time dependency
> differences; it's considered an error if a Requires.private of libfoo
> isn't found,
Really, even without --static?
> because as far as pkg-config is concerned, it means libfoo is
> dysfunctional. So we *do* need to propagate Requires.private, for the
> sake of pkg-config. (The problem mainly manifests in the form of
> ./configure scripts claiming libfoo isn't found when it's only libbar
> that's missing, because in that case pkg-config returns an error to
> the ./configure script when inquired about libfoo.)
Do you have an example of that?
> P.S.: I'll see if I can write a tool that compares the union of the
> Requires[.private] fields of all .pc files in a package to the package's
> propagated inputs, so we can detect mismatches automatically.
Would be neat!
Thanks,
Ludo’.