Re: aclocal flags are a pain

[Behdad Esfahbod]

Ralf Wildenhues wrote:
> * Behdad Esfahbod wrote on Wed, Sep 17, 2008 at 06:11:15AM CEST:
>> Behdad Esfahbod wrote:
>>> Reading autoreconf source right now.  I may just switch to it if my testers
>>> tell me it works on OS X and msys.
>> Ok, I see the following things that I like to be able to do but autoreconf
>> does not do currently:
> 
> Most of which can be had, or at least worked around, by using the
> overriding environment variables AUTOCONF, LIBTOOLIZE, ACLOCAL,
> AUTOMAKE, no?

Yes, but at that point it will be easier to just call them.

>>   * Many autogen.sh scripts I've seen try each of automake, automake-1.10,
>> automake-1.9 automake-1.8 automake-1.7 in that order to pick the first one
>> available.  I'm sure there's good reason for them doing that.  Perhaps 
>> because
>> of some stupid packaging by some distro at some time...
> 
> Which distro doesn't set plain 'automake' to be the latest version, at
> least by default?

Prolly no modern ones.  I know Debian (and maybe Ubuntu) at some point used
1.7 as automake, but had 1.8 available too.  That still was a problem anyway.

>> My autogen.sh also
>> checks for glibtoolize before libtoolize as I mentioned before.
> 
> Hmm, this is one thing that strikes me as a sensible change.
> 
>>   * My autogen.sh also checks the version of the available tools against 
>> those
>> requested in configure.ac.  Would be trivial to do in autoreconf as it 
>> already
>> traces configure.ac.
> 
> Not sure what you're after here.  The tools themselves will bail out
> anyway if they are too old (discounting automake 1.4 here).  What's
> the gain of having autoreconf bail out?

Right.  May have been old cruft for automake 1.4.  I also see that libtoolize
doesn't do the check.  Then again, the AC_PROG_LIBTOOL does not take a version
either, but for some reason we needed to add a check.  I just pass [1.4] to my
AC_PROG_LIBTOOL and use the same shell function to extract and enforce that
version in autogen.sh.

>>   * GNOME packages also need to run intltoolize and gtkdocize.  Would be nice
>> to add them in autoreconf.  I can cook a patch if there is interest.
> 
> No principled objections.  Is there a simple way to detect whether these
> need to be run?

Sure.  GTK_DOC_CHECK([1.6]) and IT_PROG_INTLTOOL([0.40.0]) for example.

Now that I checked, there are even more programs that the higher level
components of GNOME use.  So, maybe keeping them in gnome-autogen.sh is the
right way.

>>   * Not sure about this one, but I think autoreconf options --force and
>> --install kinda take my flexibility away to apply those to some of the tools
>> but not others.  For example we have a hand written INSTALL file in cairo.
>> Running "autoreconf --install --force" overrides my INSTALL file.  But I need
>> those options for the libtoolize call.
> 
> Again, use environment variables to add --force on a case-by-case basis.
> Or save and restore INSTALL.  (INSTALL is a debatable point.  There are
> good arguments for overriding it, and good ones for keeping it, with
> --force.  How to detect whether it was modified by the package author?)

I remember in one project save/restoring INSTALL and COPYING.  In the case for
cairo the INSTALL file is totally different from the one automake installs.
Maybe add a line like "Generated by automake.  Do not edit." or something now,
and at some later point only override if that is found.

> Cheers,
> Ralf

Anyway, no big deal.  You asked why we don't plain use autoreconf and these
are the immediate answers I found.

Cheers,
behdad