pkg-config v0.26 released

[Tollef Fog Heen]

]] "Daniel Macks" 

| Well sure, if you want a glib/gio that has no dbus support, something
| that until today would automatically be built, and with a certain pcre
| model that user might not want.

Yes, and I think that's fine for bootstrapping.

[...]

| I'll remind that the idea of replacing/upgrading the old internal
| glib1 with other glib modes was discussed for a while on this very
| list, and it appeared several were aware that "glib2 needs pkgconfig"
| was a problem that needed to be solved even if glib2 were to be pull
| internally and stripped down to bare essentials.

The current solution is «build a bootstrap glib 2».  I'm not interested
in bundling glib 2 with pkg-config, but if you or somebody else wants to
contribute a patch where you run

  ./configure  --with-glib-source=/some/path

and configure builds and uses that glib, I'd be willing to apply that
patch.

| Is pkg-config really that complicated that it needs a large library as
| glib, that does all sorts of cool but completely irrelevant things? Is
| "C that requires that library" the right choice to implement simple
| string-handling (breaking on whitespace, comparisons, hash/list
| collections of them)?

We certainly don't need all of glib, but having hashes, lists, string
handling and option handling is certainly something that's useful, and
it's code that adds absolutely no value by being written again.  Sure,
somebody could extract the required source files from glib, but all code
requires maintenance and I'd rather not maintain half a library for a
problem which I don't perceive as particularly big.

It's not really much more of a problem than needing some kind of
compiler to bootstrap gcc and the non-C languages in gcc need a fairly
complete libc, so you usually end up with compiling gcc, libc, gcc.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are