A specification for pkg-config

[William Pitcock]

Hi!

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.
>
> http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq
>
> 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.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=4738
>

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)
>

Yuck.

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

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

William