autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: question about configuring autotools


From: Ralf Wildenhues
Subject: Re: question about configuring autotools
Date: Wed, 12 Oct 2005 09:22:08 +0200
User-agent: Mutt/1.5.11

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]