* Eric Blake wrote on Sat, Feb 24, 2007 at 03:27:50PM CET: > > Let me recap my original observation. Currently, in order to get GNU > Autoconf onto a non-GNU system, working from GNU tarballs, you need: > > m4-1.4.x and autoconf 2.6x: [...]
ACK. > the future autoconf 3.0: > > system make > system C compiler > GNU make tarball > libtool 2.0 tarball > GNU m4 2.0 tarball > perl > autoconf 3.0 tarball Why should you need the libtool 2.0 tarball when starting with a *tarball* of GNU m4 2.0 (as opposed to with the unbootstrapped CVS sources)? The need for Libtool to be preinstalled would seem immensely depressing to me. And fixing the ChangeLog stamp rule should kill the need for GNU make, too. > According to Ralf Wildenhues on 2/24/2007 7:13 AM: > > Rather because of the brain-dead^W^W^Whelpful-for-development stamp-vcl > > updating rules that M4's Makefile.am also has. > Ouch. I basically copied the current stamp-vcl rules in M4 head from > libtool. So at this point, a solution for one project is the solution for > both. Maybe at some future time I will be able to look into it more. Is > it also worth breaking the stamp-vcl updating rules into a GNUMakefile, so > that development gets to use them, but released tarballs do not need to > see those confusing rules? Definitely. Just please make sure the GNUmakefile is also visible from a VPATH build. I hate in-tree builds, they kill testing productivity. Cheers, Ralf _______________________________________________ M4-discuss mailing list M4-discuss@gnu.org http://lists.gnu.org/mailman/listinfo/m4-discuss
