1) aclocal expects autoconf/automake macros to be hidden;
2) GTK+ hid its autoconf/automake macros;
and, if both places exist but aren't the same directory, returns a "-I"
flag to tell aclocal to look in GTK+'s directory.
Then have "autogen.sh", and Makefiles in directories with "acinclude.m4"
files, use that script and pass what flag it supplies, if any, to
aclocal.
This should, I hope, avoid problems such as those FreeBSD systems where
GTK+ was installed from a port or package (and thus stuck its macros in
"/usr/X11R6/share/aclocal") but aclocal doesn't look there.
(It doesn't solve the problem of somebody downloading and installing,
say, libtool from source - which means it probably shows up under
"/usr/local", with its macros in "/usr/local/share/aclocal" - on a
system that comes with aclocal (meaning it probably just looks in
"/usr/share/aclocal", but that may be best fixed by, whenever you
download a source tarball for something that's part of your OS,
configuring it to install in the standard system directories and
*overwriting* your OS's version.)
svn path=/trunk/; revision=2165
to add Axis ethernet vendor ID, use libtoolize in autogen.sh, and
provide the very dangerous option of installing ethereal setuid.
I've added a "DANGEROUS" comment to the description of the
--enable-setuid-install option which displays in "./configure --help".
Removed generated files tha old libltdl/.cvsignore brought to my
attention by Peter.
svn path=/trunk/; revision=1616
Add the minimum version of {autoconf,automake,libtool} required to the
message printed if it's not found (having it check to make sure you have
at least that version is a bit more work).
Update the paths for "ftp.gnu.org" to reflect the fact that they now give
each package its own subdirectory.
svn path=/trunk/; revision=1399
others are copied into the build-tree by 'automake -a'. The autogen.sh
script runs autoheader, automake, and autoconf for the developer in order
to populate a fresh CVS image with the generated build tools.
svn path=/trunk/; revision=388
