Kevin.Fox at pnnl.gov
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 err.no> 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:
> > 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?
> pkg-config mailing list
> pkg-config at lists.freedesktop.org
More information about the pkg-config