pkg-config-lite

[Dan Nicholson]

On 4/2/12, LRN <lrn1986 at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02.04.2012 22:02, Tollef Fog Heen wrote:
>> ]] Dan Nicholson
>>
>>> 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.
>>
>> Yeah, it's become a larger issue than I anticipated and I think
>> you're right that we should reconsider this.
>>
>> [...]
>>
>>> 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:
>> [snip] In time, I want to move away from glib completely, since it
>> provides so much more than what we're interested in.  We'd be ok
>> with a simple set of linked list functions, some syntactic sugar
>> for string handling and something to do the option parsing.  The
>> latter is actually the hardest point, linked lists are easy enough
>> to do ourselves.
>>
> That's exactly what i've been saying (see the previous post). Although
> convincing GLib developers to go along with it will be much harder
> than actually doing it.

If pkg-config removed it's dependency on glib, why would the glib
developers need to be convinced of anything? I don't think anyone is
suggesting that glib should suddenly change to a much slimmer library.
There are plenty of programs that make use of glib's feature set. The
point here is that pkg-config does not use that full feature set and
might be better served with another convenience library.

I personally think that as long as the bootstrapping issue can be
avoided that pkg-config does not suffer using glib. It will be
installed and already in memory on the vast majority of systems where
pkg-config is used.

--
Dan