misc/81558: AC_PROG_LIBTOOL macro is not available to automake

[Giorgos Keramidas]

The following reply was made to PR ports/81558; it has been noted by GNATS.

From: Giorgos Keramidas <keramida at ceid.upatras.gr>
To: Markus Hoenicka <markus.hoenicka at mhoenicka.de>
Cc: bug-followup at freebsd.org
Subject: Re: misc/81558: AC_PROG_LIBTOOL macro is not available to automake
Date: Mon, 30 May 2005 01:16:42 +0300

 On 2005-05-29 21:51, Markus Hoenicka <markus.hoenicka at mhoenicka.de> wrote:
 >Giorgos Keramidas writes:
 >>> The symptoms are:
 >>> - automake --add-missing --force-missing fails to install
 >>>   mkinstalldirs in the sources if there is no conf subdir.
 >>>   Manually copying the file fixes the build problem. If there is a
 >>>   conf subdirectory, a symlink is created properly
 >>
 >> I think automake looks for an option in configure.ac and puts the files
 >> in the directory specified there.  The ports version of gnu-automake is
 >> relatively old though and may be broken.
 >
 > I couldn't find a macro that would specifically control which files
 > are installed in the source tree. I'll investigate further before I
 > claim this is a bug.
 
 The AC_CONFIG_AUX_DIR() macro sets the directory where autoconf and
 automake will look for "auxiliary build tools".  This is, in my
 experience, where autotools will install all helper files too, when
 the --copy option is used.
 
 >>> - the /usr/local/gnu-autotools/share/aclocal directory is next to
 >>>   empty. If a package like the Iconv stuff installs m4 macros, they
 >>>   end up in /usr/local/share/aclocal and are therefore not available
 >>>   to the gnu version of aclocal. I know that aclocal has an --acdir
 >>>   option but this is not useful for writing portable autogen.sh or
 >>>   bootstrap.sh scripts.
 >>
 >> Hmmm, this is a problem indeed.  One that cannot be fixed by using a
 >> prefix different from /usr/local :-(
 >
 > Would that qualify as a bug? From my point of view this problem
 > renders the gnu-autotools packages pretty useless. I don't know about
 > the backgrounds of the split between bsd autotools and gnu autotools,
 > but I'd prefer to have one set of autotools on the system.
 
 It would probably qualify as a bug.  Unless the ports that need to find
 autotools can be taught to use autoconf magic to detect at install time
 where their autoconf related macros should be installed.
 
 > Should I file a bug report about this problem?
 
 I'm not sure.  The maintainer of the gnu-auto* ports should be contacted
 first, since my experience with autotools is strictly limited to the
 absolutely necessary parts that are needed for my dayjob.  I mostly
 avoid autotools when I can ;-)