RE: What does the file extension ".hg" mean?

["Gavin Lambert" <gavinl compacsort com>]

Quoth John Emmas:
> Thanks Gavin, I do appreciate that Rome wasn't built in a day and
> libraries such as gtkmm are always "works in progress".  However, when
> it comes to auto-generated sources, other libraries seem to be moving
> towards Perl, Python or (occasionally) their own, custom tools.  All of
> these tend to be usable across a wider range of compilers, which is
> highly desirable IMHO.

GTKMM *is* actually using a custom tool -- that's what gmmproc is, and it's
included in glibmm, which is a prerequisite for all the *mm libraries.  It's
just that this custom tool happens to be based around M4, with some bits of
sh and Perl thrown in (and even some C code in some cases).

> Up until recently I did in fact build all the supporting libraries from 
> tarballs - but keeping those libraries up-to-date (and in sync!) can 
> become a monumental task.  I'm trying to move towards Git (and similar) 
> as a way of simplifying that process in the future.

Up to date, I'll grant you, but I'm not really sure how using Git would help
you keep multiple libraries in sync.  In fact it seems more likely that
you'd get incompatibilities and bleeding-edge not-actually-working-yet code
that way (since they update at different times, and may not all keep the tip
clean).  Unless you're pulling only from specific release version tags,
which is little different from downloading the tarball for that release
version.  So you'd just be adding a new problem on top of your existing (and
unchanged) problem.

> By all means, keep M4 for the programmers who want it or like it but
> flexibility is important too.

Not when it introduces extra complexity for no particular benefit.  (And I'm
not saying that there is no possible benefit in what you're suggesting at
all, just that any such benefit is not clear to me from what you've said so
far -- and since you're still using the tools "wrong".)

The various *mm projects are little more than code-generation wrappers to
begin with -- as such changing the code generator essentially means
scrapping the entire thing and starting over.  And again, maybe there would
be some benefit to this (as others have pointed out, the current methods
used to update the source files when the upstream library updates are fairly
convoluted and painful at present -- but that's in part precisely because
various people have hand-rolled things in various different languages at
different times, which is an excellent example of how "flexibility" leads to
added complexity).

Besides, there *are* versions of sh and M4 and Perl and Python available for
Windows, so you *can* build the generated files from the git sources
yourself if you wish to do that.  It's more work than using the pregenerated
files from the tarballs (and you have to use the right tools); so I don't
know why you'd want to go to that effort when the tarballs are right there.
But the option is open.

And again, I'm just "some guy", not a maintainer on any of the *mm projects
(although I do have some experience with upgrading one to a newer upstream),
so you can take what I say with a grain of salt.  But I doubt things are
likely to change any time soon, as there's quite a bit of infrastructure
built up around the current codegen design.  (But, as with anything else
open-source: if you build it, they might come.)

(And, FWIW, my day job is primarily Windows based.  But I just use MinGW or
a Linux VM when I want to work on GNU-based things.)