Hi Graham, * Graham Mark wrote on Sun, Oct 09, 2005 at 09:27:16PM CEST: > > I help to support a bunch of software that uses 10-15 third-party > packages, including autotools. I'm trying to set up a directory > structure that will make it reasonably easy to replace an outdated > release of any one of these packages with its current release. "Easy" > would mean that users of these packages would not have to change > paths in makefiles or scripts, and that performing the replacement > would not be unduly burdensome. For various reasons I have to do this > outside of the usual system directories. OK. > My idea is to have a structure like this: > > .../third-party > /current > /bin > /include > /lib > ... > /autoconf-M.N > /automake-X.Y > ... > > The subdirectories under 'current' would hold pointers to appropriate > elements in autoconf-M.N, automake-X.Y, and so on. When a new version > of autoconf, say, is released, it would be installed in 'third-party' > and the current pointers would be reset to point in there. Hmm. Not going to work too well, unless you keep playing with automake-X.Y/share/aclocal/dirlist (read up on this in Automake documentation), so that aclocal finds all macros, esp the libtool ones. It should be possible do to this, though. Note that libtool links against libltdl will end up having rpaths pointing to .../third-party/libtool-x.y/lib instead of .../current/lib though, which is probably what you need but certainly not what you would expect. FWIW, I'd suggest either of two approaches: - most similar to yours: instead of $autotool-x.y, have only one, with the latest API release: autoconf-2.0/ autoconf-2.5/ (2.59 would be installed here) automake-1.4/ automake-1.5/ automake-1.6/ automake-1.7/ automake-1.8/ automake-1.9/ (1.9.6 would be installed here) libtool-1.4/ libtool-1.5/ (1.5.20 would be installed here) [ libtool-2.0/ ] and then you hit every downstream package author with a clue stick that either does not work with any of these, or requires automake < 1.9. Alternatively, if they hit you back (for the former), you come back and report the incompatibility one of the autotools has engaged in a minor update release. ;-) - a bit simpler: one prefix per automake API you need, and always the most recent of autoconf and libtool installed in each of those as well, separately (non-symlinked!) with separate --prefix configurations. > I have installed autoconf-2.59, automake-1.9.6, gcc-3.4.4 (holding > off gcc-4 for now), libtool-1.5.18, and m4-1.4.3, among others. These > were all configured with the appropriate '--prefix' flag. 'make > check' worked for all of them; 'make install' seemed OK. Yes, > When use autoconf outside of its own directory, I get errors that I > don't understand. For example, in my home directory I have a > 'configure.ac' that contains > > AC_INIT > AM_INIT_AUTOMAKE > AC_PROG_GNU_M4 > AM_MISSING_PROG > AC_CONFIG_AUX_DIR(.) > AC_CANONICAL_SYSTEM > AC_PROG_LIBTOOL > > aclocal produces > > % aclocal > configure.ac:6: warning: AC_ARG_PROGRAM was called before > AC_CANONICAL_TARGET > autoconf/general.m4:1657: AC_CANONICAL_TARGET is expanded from... > autoconf/general.m4:1660: AC_CANONICAL_SYSTEM is expanded from... Just put `AC_CANONICAL_SYSTEM' right after `AC_INIT' to fix this. > Running autoconf: > > % autoconf > configure.ac:2: error: possibly undefined macro: AM_INIT_AUTOMAKE > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. Followup error, because aclocal did not succeed (I believe). > configure.ac:3: error: possibly undefined macro: AC_PROG_GNU_M4 This is not a public Autoconf macro, it's a private one that is used to configure Autoconf itself, not third-party packages. If you need it, I guess you could use the one from Autoconf: either aclocal -I /where/autoconf/source/lies/config or cp /where/autoconf/source/lies/config/m4.m4 >> acinclude.m4 aclocal ... or, even better, if you have a macro directory in your source tree, cp /where/autoconf/source/lies/config/m4.m4 m4/ aclocal -I m4 (_then_, you may consider adding `AC_CONFIG_MACRO_DIR(m4)' to configure.ac, and `ACLOCAL_AMFLAGS = -I m4' to toplevel Makefile.am). > configure.ac:4: error: possibly undefined macro: AM_MISSING_PROG I believe this is a private macro as well. > configure.ac:7: error: possibly undefined macro: AC_PROG_LIBTOOL aclocal did not find libtool.m4. Use option `-I' to point to it, or above described `dirlist' file. > I don't really know autotools very well, and I have no idea how to > deal with this. I've tried various things, looked around the > documentation, checked the web, searched autoconf mail archives, but > I'm still stuck. I'd appreciate suggestions. I hope this gets you going a bit. Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
