mclasen at redhat.com
Mon Apr 2 19:32:38 PDT 2012
On Mon, 2012-04-02 at 21:00 +0200, Tollef Fog Heen wrote:
> ]] Dan Nicholson
> > 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.
> is, iirc, more or less from FreeBSD and gives us string buffers.
> > * GHashTable - We can obviously roll our own hash table, but it's a
> > lot nicer to lean on someone else for the dirty work.
> hcreate, hdestroy, hsearch, hcreate_r, hdestroy_r, hsearch_r - hash table management
> The non-_r versions are SVr4, so should be ok.
> They are not as nice as the glib versions, that I can agree with.
> > * GSList - Same as GHashTable.
> linked lists are trivial, or we can use something like
> > * 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.
> Yes, this is the major pain point.
> > * 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.
> Yes, hence why I'm pondering this and talking about it, rather than just
> committing the code. :-)
I must say that I don't think porting to these random alternatives of
glib apis just to avoid a circular dependency doesn't seem like a very
good use of anybodies time. Shipping a copy of the 3-5 glib source files
you actually use seems like a much more pragmatic solution.
But I'm not doing the work, so whatever works for you...
More information about the pkg-config