(Illustration by Gaich Muramatsu)
> Apparently it doesn't run libtoolize, and there is some libtool stuff > checked in to CVS. That is because they keep changing the macros, or at least shifting them between packages. It used to be automatically run when you defined the AM_PROG_LIBTOOL macro in the configure.in file, which is what we do. But now they have moved it to AC_PROG_LIBTOOL, but there is no backward compatibility for anyone using the old name. Changing to the new name ofcourse breaks it for anyone using the older autoconf tools. ugh. Well, the current cvs lost when compiling on my up-to-date netbsd system since it seemed libtool was in cvs but ltmain.sh wasn't, and the libtool m4 macros that aclocal picked up were out of sync with the libtool in cvs. So I wonder if things have to be all from the same tools, or none-run-them-all-yourself. For CVS, I favor the latter. The ones included in the Debian-stable distribution are probably reasonable representative for the average system. It has autoconf 2.53, automake 1.5, libtool 1.4.2 and I really want the build to work from distributed tarballs, although I don't care all that much for the bootstrap step needed for CVS builds. That's a perfectly good list to target for; I think auto* tries to be compatible back that far. 2.14, 1.4, and 1.2 respectively are all pretty crufty, and telling people to upgrade in that case is IMHO fine. Not that this is truth, but if debian-stable and netbsd pkgsrc are up to something (and perhaps fedora), it can be considered adequately normal to say 'sorry, you must x'. I guess automake 1.8 is kind of new; netbsd just went to 1.8.2, but it's been at 1.7.x for a while. distributed tarballs, although I don't care all that much for the bootstrap step needed for CVS builds. Not sure what you mean, but it is IMHO important for people to be able to build from CVS reasonably easily. But it's not that important for people with very old tools. I build from cvs a lot to get the bug fixes since the last release... -- Greg Troxel <gdt_at_ir.bbn.com>Received on 2004-02-23 18:37:50