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
