A specification for pkg-config

[Dan Nicholson]

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

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)

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.

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.

--
Dan