A specification for pkg-config
nenolod at dereferenced.org
Thu Sep 20 20:11:11 PDT 2012
On Wed, Sep 19, 2012 at 8:05 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> On Wed, Sep 19, 2012 at 2:15 AM, Tollef Fog Heen <tfheen at err.no> wrote:
>> ]] Dan Nicholson
>>> I think that's really great that you did that work. I've always wanted
>>> a formal spec for pkg-config. The best we have is buried in
>>> pkg-config(1). I'd love to carry a spec in the pkg-config repo and
>>> publish it on the website. This seems like a great start. There are
>>> certain bugs that I don't think can be fixed without small extensions
>>> of the syntax, and without a spec it's difficult to roll those out.
>>> Now to the specifics.
>> I don't particularly care about having a spec, but if people want to
>> write one, I'm not particularly opposed to having it. Though, it does
>> mean that we suddenly need to have a process for extending it too,
>> including formal version numbers and such.
>> Do we actually want that?
> I think we do for the file format.
I agree. The pkg-config format needs to be documented.
> I'm sure you recall how long it took for people to stop stumbling over
> the private variants because there really was no gate that said what
> side of the fence the user was on. To be fair, this was an extension to
> the format. This meant that old .pc files didn't become invalid, but
> certainly their behavior could suddenly become unpredictable out in
> the wild based on what version of pkg-config the user had. This lead
> to things like duplicated Libs and Libs.private "just in case". If there
> had been a formal version in the .pc file, then you would be forced to
> have a new enough pkg-config to handle it.
> Why am I concerned about this now? When I first started poking around
> pkg-config, Matthias Clasen pointed out what I think is a flaw. It's
> #3 in the FAQ in the guide I wrote.
> If you have a package that internally uses another library (in his
> case it was a gnome library using libgconf internally), you are
> required to add that package to Requires.private in case someone wants
> to statically link to your library. However, because we treat Cflags
> from Requires.private packages as always needed, it means you require
> the .pc file from the other package all the time. There's still a long
> bug open about this.
This is an implementation-specific problem; pkgconf does not suffer
from this particular deficiency when building it's dependency graph.
The frontend is also not affected: --exists only verifies that
top-level dependencies are resolvable without looking at .private,
unless --static is also specified.
> To me, this actually points to a more general problem where Requires
> is not specific enough. There are cases where you only need either
> Cflags or Libs from another package. It would be great if you could
> not only communicate that, but also ensure that pkg-config could avoid
> packages where you only need Libs unless --static is specified. I have
> an idea to fix this I've been kicking around, but I think I requires
> extending the syntax.
> Requires: Cflags(foo)
> Requires.private: Libs(bar)
Also: How would you suggest that --exists without --cflags or --libs
work in this condition? The only logical conclusion is that it must
still evaluate the entire dependency graph for breaks and cycles.
Also, --exists is technically implied with --cflags and --libs anyway.
Thusly, I think it is not very useful.
> What this means is that you would only return Cflags from foo and only
> Libs.private from bar when --static is used. If pkg-config was smart,
> it could skip bar.pc completely in the exceedingly common case. That
> effectively means you could have the policy that this library can be
> used without installing bar-devel if you don't care about static
> linking. That's what Matthias was after for Fedora and I had to
> convince him that pkg-config could not work that way with the current
I don't think it can work at all unless inconsistent behaviour is
allowed, and I do not believe we want inconsistent behaviour in the
toolchain, even if it is an ancillary component such as pkg-config(1).
> Anyway, supposing this change or some other one to the package format
> is desired, how would we do that effectively? I'm going to say that
> the .private method was not ideal and that the only sane way would be
> a version in the .pc file.
Yes, something along the lines of "Version: $spec-revision" as the
first line in the pkg-config file, otherwise assume it's a version 1
More information about the pkg-config