Some work I am doing at the moment

I just wanted to give people (esp. Richard and Mikael) an idea of some
stuff I am working on at the moment and also get some opinions on some
things.

A colleague at work wanted to use MrProject for keeping track of one of
our current projects, so we spent some time on Thursday and Friday
playing around and setting things up for our needs. This revealed a few
problems, so I spent the weekend up to my ears in MrProject code with
the following results:

(1) I have made a first pass at Python bindings for libmrproject. They
seem to work fairly well, although a bit of tidying up is necessary. I
wanted these for my own purposes, then I discovered they were on the
roadmap for 0.10 (bug #317). How I submit these depends on the next two
points, though...

(2) Python bindings build very nicely with automake >= 1.5, so I tried
to get everything working with automake-1.6 (this coincidentally solves
bug #411 in a less hackish fashion). That took a couple of days and I
now have a document that will be useful to the GNOME community at large.
This was actually a pretty useful test case for the whole upgrade issue.

Two problems of note here:

	(a) There is a major bug in intltool that needs to be fixed
	first before mrproject can be moved to automake-1.6. I have
	submitted this and it should be too controversial (given that
	the previous code did not have any chance of working), but the
	build patch blocks on that.

	(b) Gettext ... arrgh!
	
OK, here's the deal: glib-gettextize, which is currently being used, was
designed to work around a couple of moments of madness on the part of
the gettext maintainers (when they were writing to Changelogs, etc) and
to handle the GETTEXT_PACKAGE variable so that parallel installs of
GLib, GTK+, etc could be done. Those packages had both versions 1 and 2
having PACKAGE (set by configure) being the same, but the message
domains needed to be different. Unfortunately, glib-gettextize cannot be
used with automake-1.6 for a number of reasons. Plus, it is fairly old
and does not track recent gettext developments.

Currently, there does not appear to be any GNOME package that uses
gettext and automake-1.6, except vte which does not pass distcheck, as
far as I can tell. So we are breaking new ground for GNOME here.

The solution I came up with involves a small amount of pain initially
and then should be reasonably future-proof. I would like to propose that
we move to gettext-0.11.4 or later.

Advantages:
	- the gettext maintainers have stopped writing to ChangeLog
	  files and messing about with other files after the initial
	  upgrade.
	- a tool called autopoint exists, which performs the same
	  function as glib-gettextize in the sense that you do not need
	  to check in the files that are otherwise shipped with gettext.
	  The autopoint script copies them into the source directory
	  during the autogen.sh phase.
	- The need for GETTEXT_PACKAGE in po/Makefile.in.in is
	  deprecated, since you can set the domain explicitly.

Disadvantages:
	- everybody building from CVS will require at least version
	  0.11.4. This is not bad, since it's been out for eight months
	  or so now, but it's worth considering.
	- this is not a backwards compatible change. Once the move to
	  gettext-0.11.x is made, we _have_ to use automake >= 1.5. So
	  it's all or nothing.

The alternative to upgrading the gettext requirement is to ship a local
version of glib-gettextize or check in the generated Makefile.in.in.
However, both of these will require us to track any bug fixes ourselves
and are just holdover measures until one day switching to a later
gettext. My vote is obviously to upgrade, but I am just one little guy
(and not a maintainer), so I would like to hear some arguments either
way.

There are currently no concrete plans in the GLib community to upgrade
glib-gettextize. Owen knows that it will have to be done one day, but he
is apparently undecided about whether to upgrade that script or just use
the latest gettext.

If there is a concern that the gettext maintainers will, at some point
in the future, do more silly things such as the huge gettextize changes
in the recent past, we can then switch to a glib-gettexize style script.

So, _if_ requiring gettext-0.11.4 or later is deemed acceptable, I have
a series of patches that upgrades libmrproject and mrproject to use
automake-1.6 or automake-1.7 (they pass 'make distcheck'). This makes
the Python bindings trivial to build and so I then have a patch to
libmrproject that gives us Python bindings. It is not impossible,
obviously, to make the Python bindings build with the older automake,
but it is a lot more work and I am seriously doubting whether the effort
required to maintain that for a short time until sticking with
automake-1.4 becomes too painful is worth it.

I also have patches to tidy up all of the errors and warnings that are
spat out by the API documentation building process in libmrproject.
However, I will wait for a decision on the above before submitting
those, since they are currently patches on top of the build changes and
I will need to redo them against the current build stuff if the upgrade
idea is killed.

If all of this just sounds like too much effort and you don't want it,
I'm not going to be offended. I have learnt some useful stuff doing it
and it makes my life easier, but I am not going to spit the dummy if you
just want a less troublesome life at the moment.

Cheers,
Malcolm

-- 
Many are called, few volunteer.