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.)
svn path=/trunk/; revision=2165
2000-07-26 08:03:57 +00:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# This script returns the flags to be fed to "aclocal" to ensure that
|
|
|
|
# it finds GTK+'s aclocal macros.
|
|
|
|
#
|
|
|
|
# aclocal will search, by default, only in a directory in the same
|
|
|
|
# tree where it was installed - e.g., if installed in "/usr/bin", it'll
|
|
|
|
# search only in "/usr/share/aclocal", and if installed in "/usr/local/bin",
|
|
|
|
# it'll search only in "/usr/local/share/aclocal".
|
|
|
|
#
|
|
|
|
# However, there is no guarantee that GTK+ has been installed there; if
|
|
|
|
# it's not, it won't find the GTK+ autoconf macros, and will complain
|
|
|
|
# bitterly.
|
|
|
|
#
|
|
|
|
# So, if the "share/local" directory under the directory reported by
|
|
|
|
# "gtk-config --prefix" isn't the same directory as the directory
|
|
|
|
# reported by "aclocal --print-ac-dir", we return a "-I" flag with
|
|
|
|
# the first of those directories as the argument.
|
|
|
|
#
|
|
|
|
# (If they *are* the same directory, and we supply that "-I" flag,
|
|
|
|
# "aclocal" will look in that directory twice, and get well and truly
|
|
|
|
# confused, reporting a ton of duplicate macro definitions.)
|
|
|
|
#
|
2004-07-18 00:24:25 +00:00
|
|
|
# $Id$
|
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.)
svn path=/trunk/; revision=2165
2000-07-26 08:03:57 +00:00
|
|
|
#
|
|
|
|
|
|
|
|
#
|
|
|
|
# OK, where will aclocal look by default?
|
|
|
|
#
|
|
|
|
aclocal_dir=`aclocal --print-ac-dir`
|
|
|
|
|
|
|
|
#
|
|
|
|
# And where do we want to make sure it looks?
|
|
|
|
#
|
2004-07-03 21:35:30 +00:00
|
|
|
gtk_prefix=`gtk-config --prefix 2>/dev/null`
|
2000-11-22 04:03:22 +00:00
|
|
|
|
|
|
|
if [ -z "$gtk_prefix" ]
|
|
|
|
then
|
|
|
|
gtk_aclocal_dir=""
|
|
|
|
else
|
|
|
|
gtk_aclocal_dir=$gtk_prefix/share/aclocal
|
|
|
|
fi
|
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.)
svn path=/trunk/; revision=2165
2000-07-26 08:03:57 +00:00
|
|
|
|
2003-01-22 00:19:00 +00:00
|
|
|
ac_missing_dir=`dirname $0`
|
2004-03-04 08:25:23 +00:00
|
|
|
echo "-I $ac_missing_dir/aclocal-fallback" | tr -d '\012' | tr -d '\015'
|
2003-01-22 00:19:00 +00:00
|
|
|
|
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.)
svn path=/trunk/; revision=2165
2000-07-26 08:03:57 +00:00
|
|
|
#
|
|
|
|
# If there's no "aclocal", the former will be empty; if there's no
|
|
|
|
# "gtk-config", the latter will be empty.
|
|
|
|
#
|
|
|
|
# Add the "-I" flag only if neither of those strings are empty, and
|
|
|
|
# they're different.
|
|
|
|
#
|
2002-03-06 06:36:22 +00:00
|
|
|
if [ ! -z "$aclocal_dir" -a ! -z "$gtk_aclocal_dir" \
|
|
|
|
-a "$aclocal_dir" != "$gtk_aclocal_dir" ]
|
|
|
|
then
|
2003-01-22 15:58:33 +00:00
|
|
|
echo " -I $gtk_aclocal_dir" | tr -d '\012' | tr -d '\015'
|
2002-03-06 06:36:22 +00:00
|
|
|
fi
|
2003-01-22 00:19:00 +00:00
|
|
|
echo
|
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.)
svn path=/trunk/; revision=2165
2000-07-26 08:03:57 +00:00
|
|
|
exit 0
|