pkg-config-lite

[Dan Nicholson]

On Fri, Mar 30, 2012 at 10:57 PM, Tollef Fog Heen <tfheen at err.no> wrote:
> ]] Paul Bender
>
>> On 3/30/2012 9:49 PM, Tollef Fog Heen wrote:
>> > ]] Paul Bender
>> >
>> >> Making pkg-config dependent on anything will ensure that pkg-config is
>> >> dropped over time. The inane idea that it is ok to make pkg-config
>> >> depend on a package that uses pkg-config is sure to guarantee that
>> >> distributions will not update pkg-config. I maintain a Linux
>> >> distribution and I have no plans to upgrade pkg-config because of the
>> >> the inane decision to create this dependency. Because of this
>> >> decision, I expect that within five years pkg-config will no longer
>> >> exist. Nobody maintaining a distribution wants this circular
>> >> dependency. Therefore, we will end up dropping pkg-config.
>> >
>> > Such a circular dependency is quite common in lower parts of the
>> > toolchain, so people bootstrapping distributions have to deal with this
>> > anyway.  For people not maintaining toolchains, it's not a problem.
>>
>> It is not "quite common". I maintain a toolchain, so I know. The only
>> circular dependency is between gcc and glibc. Based on your statement
>> you must not maintain a toolchain.
>
> There are quite a few more packages that need themselves to build, such
> as ghc or sbcl.  http://wiki.debian.org/CircularBuildDependencies talks
> about 20 of them.

Hi Tollef,

I think you've made it clear that you don't think having the build
loop is an issue, but I think for plenty of users it has become an
issue. I've seen this problem sited on this list and in other
locations. The difference between this situation and those listed on
the debian page is that pkg-config is a core part of a distribution's
build infrastructure. I think it's being unnecessarily problematic to
create a bootstrap issue so low in the stack.

So, would you be open to adding a default off internal glib if I
maintain it? I already had it working a year or so ago and was just
refreshing my patches last week for the latest glib stable. Most of
the time it would just live in the tree collecting dust, unlike the
old internal glib that unpacked itself every time you ran autogen.sh.
The tree looked like this in my previous work:

http://cgit.freedesktop.org/~dbn/pkg-config/tree/?h=glib2

I certainly think you have a valid position that people should be able
to work around this issue. If nothing changes, I still think it would
be a completely reasonable story. However, I think we would serve our
users best to help them work around the build loop we've created. If
you look at a gcc tarball, you'll see that it isn't nearly as
self-contained as you'd think. They depend on 2 or 3 external
libraries like libgmp and libmpfr. But they go to the burden of
carrying internal copies of those libraries so that people can easily
grab, build and use the compiler. I think it would be better if
pkg-config helped people like that.

--
Dan