On Sun, 2004-01-18 at 23:33, Henning Makholm wrote: > Scripsit Scott James Remnant <scott@netsplit.com> > > On Sat, 2004-01-17 at 20:24, Henning Makholm wrote: > > > > Anybody got a good automatic way of checking whether a configure.in > > > will require nontrivial porting for use on 2.5x? > > > Run autoupdate and see if it explodes? > > Possibly. Is it easy to notice the explosion mechanically? > I'm not sure whether autoupdate completely bails out if it can't complete its job, I've never encountered a configure script it hasn't managed to fix up (but then I've not really used it a huge deal either). Probably checking whether the configure script has changed, or whether autoconf works, is good enough for an automated procedure. > When I tried to rerun aclocal & autoconf (not libtoolize) for a package > on a system that had the wrong version of /usr/share/aclocal/libtool.m4 > installed, what I got was an error that did not manifest until *build* > time. Not an error from autoconf; not an error from the generated > configure script. Only when the build process reached 'make all' did > things begin to go visibly wrong. > Yeah, libtool can't tell it was made with the wrong version of libtool.m4 -- this is an old bug, and is in fact what I'm working on right now (for 1.6). > > > Therefore, I hold that if we remove libtool1.4, then it becomes a bug > > > if the internal configuration infrastructure in a package cannot be > > > rebuilt without having libtool1.4 installed. > > > There isn't any reason you'd want to run libtoolize again though, unless > > you intend to update to 1.5. > > No, but /usr/bin/libtoolize is not the only thing provided by the > libtool package. > > As described above, not having the correct libtool available means > that one cannot regenerate the *configure* script, and there are all > sorts of reaons to want to do that, even as a Debian maintainer. > Actually, this is wrong. You can happily update the configure script without either the libtool1.4 or libtool packages installed. What you cannot do is update aclocal.m4 using the 'aclocal' tool, and quite frankly if you're still stuck on Autoconf 2.13 you should *NOT* be doing this anyway. Most of the stuff I found in /usr/share/aclocal seems to assume you're running Autoconf 2.5x these days. This is all being slowly phased out though, and instead we're moving towards gettextize/autopoint/libtoolize and their ilk placing their m4 files in your application's source directory, so aclocal 1.8 can add m4_include() lines to aclocal.m4 rather than including them verbatim. This is actually a good solution to this problem as well, if you place libtool 1.4's libtool.m4 in the source directory of the app you can't update, aclocal will (generally) do the right thing. I'm half tempted to place the old 1.4 ltmain.sh and libtool.m4 in /usr/share/doc/libtool/historic (of the libtool package) so that they can be still gotten at. That could be a good enough compromise for the time being. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part