Re: intltool configure problem

[Malcolm Tredinnick <malcolm commsecure com au>]

On Fri, 2004-07-23 at 16:31 +0200, Jordi Mallach wrote:
> On Fri, Jul 23, 2004 at 02:36:45PM +0100, Dafydd Harries wrote:
> > > Can anyone look at 14502 and judge if my patch is acceptable?
> > I assume you mean bug #145027. :)
> 
> Sigh, I pasted that 14502 shit all over IRC too ;)
> 
> > It would be nice if your patch worked with Automake 1.8 as well -- can
> > you test this?
> 
> Not right now, as gnome-common 2.4 doesn't have automake1.8 support yet.
> Malcolm has been working on that though, and said would have a commit
> ready soonish. I don't know what the status of that is right now.
> 
> That'd be all that is needed to support automake 1.8.

Well, let's be clear about what is going on here, since there are really
two problems at work:

Firstly, there is the issue of making as many GNOME packages as possible
automake-1.8 "safe". Already (and for many months) gnome-common has
happily used automake-1.8 if that was all you had available and you
requested automake-1.5 or later (you can even set
AUTOMAKE_REQUIRED_VERSION=1.8). But that is not guarantee that things
would always work, since there were some assumptions that became invalid
when automake-1.8 was released. So part of what I am doing at the moment
is building each module from a completely clean slate and only using
automake-1.8 then fixing any problems in a way that is compatible with
earlier automake versions as well. I also do not feel comfortable
dictating that everybody updates their build tools to the absolute
latest (putting me at odds with large portions of the Debian project,
for example), but I am not against asking people to move into the 21st
century and leave automake-1.4 behind, for example.

The second problem is intltool's build patches. As many people are
probably aware, intltool patches the Makefile.in.in file that is created
by gettext in the po/ directory of each package. This is the file that
becomes the file that is responsible for creating your beloved *.po
files and turning them into *.gmo files at installation time -- the
patches make it "intltool-aware" so that translations are sucked out of
more than just source code files. The patch that intltool applies to
this file is a bit dependent on both the gettext and automake versions.
Up until now, only gettext has caused us some late nights fixing
problems. With automake-1.8, the maintenance pain has expanded. I have
some intltool fixes that I am testing at the same time as I am testing
the above changes, but I don't think I have fixed things completely yet.

Build a GNOME CVS checkout from scratch and you will encounter a number
of problems (about 10 when I tried this two weeks ago) with
mkinstalldirs being called, for example, that are due to intltool and
recent automake interactions.

I really need to test build the whole platform before sending the patch
to CVS. You can all imagine precisely how popular I will (not) be if
some build patch breaks half the packages for some common setup (again,
it needs to work for a few recent automake versions, etc). In fact, I am
seriously considering forging the eventual patch submission email so
that it looks like it comes from somebody with street-credibility like
Jordi just so that I don't get blamed. :-)

Cheers,
Malcolm