[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: aclocal flags are a pain
Re: aclocal flags are a pain
Wed, 17 Sep 2008 02:40:31 -0400
Thunderbird 18.104.22.168 (X11/20080501)
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
>> 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
>> requested in configure.ac. Would be trivial to do in autoreconf as it
>> 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
>> * 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.
Anyway, no big deal. You asked why we don't plain use autoreconf and these
are the immediate answers I found.