Kevin Fox Kevin.Fox at
Tue Apr 3 09:42:09 PDT 2012

On Mon, 2012-04-02 at 11:25 -0700, Dan Nicholson wrote:
> On 4/2/12, Tollef Fog Heen <tfheen at> 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
> >> The tree looked like this in my previous work:
> >
> > If it's default-off, I wouldn't really mind so much, no.  It then
> > becomes mainly a «the download is significantly larger than it ought to
> > be», but bandwidth generally isn't that much of a problem.
> >
> > 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.
> I think the things that are used from glib and/or popt are:
> * GSting - I'd really rather not go back to managing strings manually.
> * GHashTable - We can obviously roll our own hash table, but it's a
> lot nicer to lean on someone else for the dirty work.
> * GSList - Same as GHashTable.
> * poptParseArgvString/g_shell_parse_argv - Converts the Cflags/Libs
> command lines into argument vectors with all the quoting/escaping
> magic. I'd rather not rewrite that code.
> * poptOption/GOption - We could convert to getopt eventually, although
> these guys do have some nice sugar.
> So, it's doable, but it could be in for some bumpy waters while corner
> cases come to light.

Would it make sense to do a libglib-lite here? I'm guessing all those
features would be pretty self contained. You could write a script that
pulled just the c files that you need from the specified glib source
tree and fill in the blanks with some typedefs and a little bit of code?


> > So, feel free to commit.
> OK, I'll get something in later this week that uses the latest glib
> stable release and ping people to test it out. How do you feel about
> the no-popt patchset?
> --
> Dan
> _______________________________________________
> pkg-config mailing list
> pkg-config at

More information about the pkg-config mailing list