Add a script, "aclocal-flags", which figures out where
authorguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Wed, 26 Jul 2000 08:03:57 +0000 (08:03 +0000)
committerguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Wed, 26 Jul 2000 08:03:57 +0000 (08:03 +0000)
commit9511862fbf4e001b8c5c9c64d6b0658e3e237052
treed41bec83539106676f39a43b43d39756172d79f7
parentb4123b84de8263c21bfad9d3ac1839d4dcf44a8e
Add a script, "aclocal-flags", which figures out where

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.)

git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@2165 f5534014-38df-0310-8fa8-9805f1628bb7
Makefile.am
aclocal-flags [new file with mode: 0755]
autogen.sh
wiretap/Makefile.am