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
|
2011-04-14 02:49:20 +00:00
|
|
|
# it finds GLib's aclocal macros (we assume GTK+ is installed in the
|
|
|
|
# same place as GLib) and pkg-config's aclocal macros.
|
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
|
|
|
#
|
|
|
|
# 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".
|
|
|
|
#
|
2011-04-14 02:49:20 +00:00
|
|
|
# However, there is no guarantee that GLib, or pkg-config has been installed
|
|
|
|
# there; if either of them hasn't been installed there, aclocal won't find
|
|
|
|
# the autoconf macros for whichever of them wan't, and will complain
|
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
|
|
|
# bitterly.
|
|
|
|
#
|
2011-04-14 02:49:20 +00:00
|
|
|
# So:
|
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
|
|
|
#
|
2011-04-14 02:49:20 +00:00
|
|
|
# if pkg-config is found with a path that ends with "bin/pkg-config",
|
|
|
|
# and the "share/local" directory under the directory at the path
|
|
|
|
# that's the part of the pkg-config path preceding "bin/pkg-config"
|
|
|
|
# isn't the same directory as the directory reported by "aclocal
|
|
|
|
# --print-ac-dir", we include in our output a "-I" flag with that
|
|
|
|
# directory as its argument;
|
|
|
|
#
|
|
|
|
# if the "share/local" directory under the directory reported by
|
|
|
|
# "pkg-config --variable=prefix glib-2.0" isn't the same directory
|
|
|
|
# as the directory reported by "aclocal --print-ac-dir", we include
|
|
|
|
# in our output a "-I" flag with the first of those directories as
|
|
|
|
# the argument.
|
|
|
|
#
|
|
|
|
# If either of them *is* the same directory as the directory reported by
|
|
|
|
# "aclocal --print-ac-dir", 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. This also means that if pkg-config
|
|
|
|
# and Glib are installed with the same prefix, we should only supply one
|
|
|
|
# "-I" flag for both of them.
|
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
|
|
|
#
|
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?
|
2011-04-14 02:49:20 +00:00
|
|
|
# Look for pkg-config first.
|
|
|
|
#
|
2013-08-12 17:16:08 +00:00
|
|
|
pkg_config_path=`command -v pkg-config 2>/dev/null`
|
2011-04-14 02:49:20 +00:00
|
|
|
if [ -z "$pkg_config_path" ]
|
|
|
|
then
|
|
|
|
#
|
2013-08-12 17:16:08 +00:00
|
|
|
# Either we don't have "command" (which is required by recent
|
|
|
|
# POSIX) or it didn't find pkg-config.
|
2011-04-14 02:49:20 +00:00
|
|
|
#
|
|
|
|
pkg_config_aclocal_dir=""
|
|
|
|
else
|
|
|
|
#
|
|
|
|
# OK, we found pkg-config; attempt to find the prefix for it, by
|
|
|
|
# stripping off "bin/pkg-config".
|
|
|
|
#
|
|
|
|
pkg_config_prefix=`expr "$pkg_config_path" : '\(.*\)/bin/pkg-config'`
|
|
|
|
if [ -z "$pkg_config_prefix" ]
|
|
|
|
then
|
|
|
|
#
|
|
|
|
# Well, we couldn't strip it off, for whatever reason.
|
|
|
|
#
|
|
|
|
pkg_config_aclocal_dir=""
|
|
|
|
else
|
2012-09-16 01:49:59 +00:00
|
|
|
#
|
|
|
|
# Solaris 11's default pkg-config installation puts
|
|
|
|
# it in /usr/ccs/bin, but there's no /usr/ccs/share.
|
|
|
|
# Map /usr/ccs to /usr.
|
|
|
|
#
|
2013-08-12 17:16:08 +00:00
|
|
|
# Ubuntu 7.10 has /usr/X11R6/bin as a symbolic link
|
|
|
|
# to /usr/bin, but there's no /usr/X11R6/share. If
|
|
|
|
# /usr/X11R6/bin is a symlink to /usr/bin, map
|
|
|
|
# /usr/X11R6 to /usr.
|
|
|
|
#
|
2012-09-16 01:49:59 +00:00
|
|
|
if [ "$pkg_config_prefix" = /usr/ccs ]
|
|
|
|
then
|
|
|
|
pkg_config_prefix=/usr
|
2013-08-12 17:16:08 +00:00
|
|
|
elif [ "$pkg_config_prefix" = /usr/X11R6 ]
|
|
|
|
then
|
|
|
|
if expr "`ls -ld /usr/X11R6/bin`" : '.*/usr/X11R6/bin -> .*/bin$' >/dev/null
|
|
|
|
then
|
|
|
|
pkg_config_prefix=/usr
|
|
|
|
fi
|
2012-09-16 01:49:59 +00:00
|
|
|
fi
|
|
|
|
|
2011-04-14 02:49:20 +00:00
|
|
|
#
|
|
|
|
# Now get the path of its aclocal directory.
|
|
|
|
#
|
|
|
|
pkg_config_aclocal_dir=$pkg_config_prefix/share/aclocal
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
|
|
|
#
|
|
|
|
# Now see where glib is installed.
|
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
|
|
|
#
|
2009-06-28 17:23:07 +00:00
|
|
|
glib_prefix=`pkg-config --variable=prefix glib-2.0 2>/dev/null`
|
2000-11-22 04:03:22 +00:00
|
|
|
|
2011-04-14 02:49:20 +00:00
|
|
|
#
|
|
|
|
# Now get the path of its aclocal directory.
|
|
|
|
#
|
2009-06-28 17:23:07 +00:00
|
|
|
if [ -z "$glib_prefix" ]
|
2000-11-22 04:03:22 +00:00
|
|
|
then
|
2009-06-28 17:23:07 +00:00
|
|
|
glib_aclocal_dir=""
|
2000-11-22 04:03:22 +00:00
|
|
|
else
|
2009-06-28 17:23:07 +00:00
|
|
|
glib_aclocal_dir=$glib_prefix/share/aclocal
|
2000-11-22 04:03:22 +00:00
|
|
|
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
|
|
|
|
2011-04-14 02:49:20 +00:00
|
|
|
#
|
|
|
|
# Add our aclocal-fallback to the path.
|
|
|
|
# We write out the -I flag for it, and strip off CR and LF, as we may
|
|
|
|
# be writing more -I options, and we want all the options to be on
|
|
|
|
# one line.
|
|
|
|
#
|
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
|
|
|
#
|
2011-04-14 02:49:20 +00:00
|
|
|
# If there's no aclocal, aclocal_dir, which is the path where aclocal
|
|
|
|
# searches, will be empty; if we didn't find pkg-config,
|
|
|
|
# pkg_config_aclocal_dir, which is the path where it should search
|
|
|
|
# for pkg-config's macros, will be empty. Add pkg_config_aclocal_dir only
|
|
|
|
# if both it and aclocal_dir are non-empty and different from each other.
|
|
|
|
#
|
|
|
|
if [ ! -z "$aclocal_dir" -a ! -z "$pkg_config_aclocal_dir" \
|
|
|
|
-a "$aclocal_dir" != "$pkg_config_aclocal_dir" ]
|
|
|
|
then
|
|
|
|
echo " -I $pkg_config_aclocal_dir" | tr -d '\012' | tr -d '\015'
|
|
|
|
fi
|
|
|
|
|
|
|
|
#
|
|
|
|
# If pkg-config doesn't know about glib-2.0, glib_aclocal_dir will be
|
|
|
|
# empty. (Should we just fail in that case? Does that mean we don't
|
|
|
|
# have GLib installed?)
|
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
|
|
|
#
|
2011-04-14 02:49:20 +00:00
|
|
|
# Add glib_aclocal_dir only if both it and aclocal_dir are non-empty and
|
|
|
|
# different from each other *and* pkg_config_aclocal_dir is different from
|
|
|
|
# glib_aclocal_dir. (We don't need to check whether pkg_config_aclocal_dir
|
|
|
|
# is empty; if it is, then either glib_aclocal_dir is also empty, in which
|
|
|
|
# case we'll bail out before even looking at pkg_config_aclocal_dir, or
|
|
|
|
# it's non-empty, in which case it obviously won't be equal to
|
|
|
|
# pkg_config_aclocal_dir.)
|
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
|
|
|
#
|
2009-06-28 17:23:07 +00:00
|
|
|
if [ ! -z "$aclocal_dir" -a ! -z "$glib_aclocal_dir" \
|
2011-04-14 02:49:20 +00:00
|
|
|
-a "$aclocal_dir" != "$glib_aclocal_dir" \
|
|
|
|
-a "$pkg_config_aclocal_dir" != "$glib_aclocal_dir" ]
|
2002-03-06 06:36:22 +00:00
|
|
|
then
|
2009-06-28 17:23:07 +00:00
|
|
|
echo " -I $glib_aclocal_dir" | tr -d '\012' | tr -d '\015'
|
2002-03-06 06:36:22 +00:00
|
|
|
fi
|
2011-04-14 02:49:20 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# Put out the final line ending.
|
|
|
|
#
|
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
|