Thoughts on mm-common and gmmproc

[Krzesimir Nowak <qdlacz gmail com>]

Hi,

I had these thoughts brewing in my head since a while, so I'll try today
write them down in maybe clean manner, as I am not fluent in pouring my
thoughts to written or spoken word.

mm-common describes itself as a set of tools and macros for maintainers
only, so it avoids being a dependency when building modules from
tarball. gmmproc is also a tool for maintainers, so shouldn't it be
moved to mm-common instead of keeping it in glibmm?

Also, mm-common ships its own doxytag of libstdc++, which points to
latest version - it has a drawback: I downloaded glibmm docs package for
fedora 12 [1] and noticed that links to stdc++ docs are outdated - I
wanted to see std::vector docs, but got std::numeric_limits<float> page.
Maybe getting doxytag from latest stable would be better?

Some people (Daniel, Murray, probably others, citations needed) said
that it would be good to rewrite gmmproc (in python). I'd rather won't
agree - gmmproc for sure is not perfect, but it could be refactored.
Rewrites tend to throw away fixes and tricks in old software and present
many new bugs. And also - rewriting it is too time-consuming (see:
Netscape 6).

Here are things, that could be IMHO changed in defs and sources
generation stage:

- gmmproc now is executed for every .hg file available. That causes
multiple, time-consuming loading defs and XML documentation from slow
hardrive, parsing/splitting/processing them just to produce three files
and then throw it all away, and then load/parse them again a while later
for another .hg file and so on. Better option could be just load/parse
them once, then process all templates. I haven't looked at its internals
very deep, but probably running m4 once on all g1 files (or one huge
file) will be even harder, since in some templates temporary conversions
are specified.

- gmmproc spits an awful lot of warnings and other infos during wrapping
which sometimes makes hard to actually hunt bugs (like #606100 [2]) - I
think this is partially defs fault (like in GChecksum), but couldn't be
some warnings just quieted? Now, I got sort of warning blindness, like
people surfing on Internet have banner blindness. I take seriously only
warnings printed by Output.pm.

- I was wondering if current defs file format is all that great. Why not
use XML for example? True, it can get quite lengthy, but there are lots
of software parsing this stuff and format is rather quite reliable -
unpaired parentheses and usage of double quotes in property docs aren't
going to screw anything and <, >, & could be replaced with &smth;
entities.

- Generating defs file is the horror story. For signals defs - compile
and run a little program, for enums defs - run an enum.pl script, for
methods defs - h2def.py, for xml docs - docextract_to_xml.py, for vfuncs
defs - just write them by hand. Le gasp! Also, some of these tools are
not perfect or fine-tuned for mm-modules needs - pygobject's
docextract_to_xml.py does not extract enum documentation, h2def.py
hickups on functions with a pointer to function as their parameter (some
g_test function has them). I'd rather avoid writing Another Defs or XML
Generating Tool to have enum docs. But frankly speaking this is sort of
hard to resolve with one tool at first glance. Also, I recently tried to
regenerate all defs for atkmm, gdkmm and gtkmm and in the end I got some
cryptic error about end of file while wrapping GtkSettings, so updating
defs is also painful.

- Language galore - gathering Lisp defs and generating C++ sources are a
cake made of python, perl and m4, sprinkled with sh and served on
autotools dishes. :)

Well, the third and fourth dashes are sort of writing a software from
scratch or making deeper changes in already written one, but they bring
much to feeling that generation stage could be better.

With mm-common introduction, I think that defs generation is only part
of build system I'd describe as rickety improvisation and gmmproc just
needs some love.

Krzesimir

[1]
http://kojipkgs.fedoraproject.org/packages/glibmm24/2.22.1/1.fc12/i686/glibmm24-doc-2.22.1-1.fc12.i686.rpm
[2] https://bugzilla.gnome.org/show_bug.cgi?id=606100