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

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

2013-06-23 13:08, John Emmas skrev:
> On 23/06/2013 10:13, Kjell Ahlstedt wrote:
> > Hi John,
> >
> > Did you copy the source code from the git repository? If you do that, 
> > you need several tools to build glibmm
>
> Thanks for that, Kjell,
>
> Interestingly enough, I've managed to build the entire GTK+ stack from 
> Git Sources (over 70 x DLL's) without needing anything from Msys / 
> Bourne Shell / autotools etc.  Of course, there was a lot of 
> auto-generated stuff to deal with but I managed to figure it all out.  
> I only had glibmm and gtkmm left to do (and perhaps atkmm). For the 
> other libraries I wrote a simple perl script to do the various 
> configurations and substitutions (i.e. the stuff that usually gets 
> done by autoconf).  But the substitutions needed for glibmm are 
> probably outside its scope, so I guess I'll have to revert to tarballs 
> for these final three libraries.  What a pity... :-(
>
> I'm probably being a bit dim here - but given that glibmm is a simple 
> wrapper around glib, why is it necessary for any of it to get 
> auto-generated?  Surely the wrappers are (pretty much) set in stone?
>
> Or is it clever enough to examine glib and automatically add / update 
> things as glib gets updated?
Yes, to some extent gmmproc gets information from glib's source files. 
But perhaps more important, gmmproc can generate quite a lot of code 
from a single-line macro. Look at a _WRAP_METHOD or (even better) a 
_WRAP_SIGNAL macro in an .hg file, and compare to the code generated by 
it in the corresponding .h and .cc files, and the documentation 
generated in the .h file.

The updating is far from automatic, though. New glib methods require 
manually added _WRAP_METHOD macros. And the information from the glib 
sources are first extracted by some Python scripts in 
glib/tools/defs_gen, and stored in the .defs files in the src 
directories. This is described in an appendix in the gtkmm tutorial,
https://developer.gnome.org/gtkmm-tutorial/stable/chapter-wrapping-c-libraries.html.en
I suspect that it's more complicated than necessary, probably for 
historical reasons. The mixture of Perl, Python and M4 makes it 
difficult to maintain. Not many people are proficient in all three.

Kjell