Re: The autoconf macros business.
- From: Tim Janik <timj gtk org>
- To: Miguel de Icaza <miguel nuclecu unam mx>, Owen Taylor <otaylor gtk org>
- cc: gnome-hackers nuclecu unam mx, gnome-devel-list gnome org
- Subject: Re: The autoconf macros business.
- Date: Sat, 10 Apr 1999 00:42:12 +0200 (CEST)
On Fri, 9 Apr 1999, Miguel de Icaza wrote:
> Hello fellow hackers,
> It has been brought to my attention that our current .m4 file setup
> is not quite adecuate. Currently we require every package to include
> the "macros" directory to be able to run the autogen.sh script and
> generate a proper configure file.
> Now, this is just dandy for CVS, but consider the average GNOME
> programmer that is using the released tarballs. How can he easily
> use our macros to detect if GNOME is installed, if the objective-c
> thign works, if ghttp is available?
> Currently he can not. He needs to copy the "macros" dir from an
> existing and working project.
uhm, that reminds me...
first, i've run into this problem as well (with a project that i'm still
keeping in closed development) and i basically ended up with:
dnl Check for Gtk+
AC_MSG_ERROR(Cannot find GTK+ - gtk-config missing from path?)
dnl Check for GNOME, we override PROJECT_CFLAGS and PROJECT_LIBS here,
dnl because GNOME already takes care of Gtk+, and we already checked
dnl that the Gtk+ version is sufficient.
AC_MSG_CHECKING(for GNOME - version >= 1.0.0)
if gnome-config --version >/dev/null 2>&1; then
GNOME_VERSION=[`gnome-config --version | sed 's/^[^0-9]*//'`]
case "$GNOME_VERSION" in
*[)] AC_MSG_ERROR(GNOME $GNOME_VERSION is not known to work with $PROJECT);;
PROJECT_CFLAGS=`gnome-config --cflags gnomeui`
PROJECT_LIBS=`gnome-config --libs gnomeui`
AC_MSG_ERROR(Cannot find GNOME - gnome-config missing from path?)
which is obviously not as nice as AM_PATH_GNOME(1.0.0, , ) would be...
apart from that, watch the above sed command, this is neccessary because
$ glib-config --version
$ gtk-config --version
i think gnome-config is broken in outputting the preceeding "gnome-libs " for the
another problem is featuring additional modules/libraries, while
$ glib-config gthread --libs
-L/usr/local/lib -lgthread -lglib -lpthread
$ gtk-config gthread --libs
-L/usr/local/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule \
-lgthread -lglib -lpthread -ldl -lXext -lX11 -lm
works nicely, gnome-config does:
gnome-config gthread --libs
Unknown library `gthread'
(passing "gmodule" instead of "gthread" is even worse as that isn't even
featured by gtk-config).
we need to fix this in a consistent way somehow.
a possible solution to this (this is just a quick-thought, developed while
i'm writing this mail, so there may be some drawbacks/flaws in my suggestions)
might be adding a --quiet and --list-libs flags to all three scripts.
--quiet for returning an error code without issuing a
warning if a library name isn't recognized, and --list-libs to construct the
help screen by chaining lower level scripts.
another inconsistency is
$ glib-config --cflags --libs # default: "glib"
$ gtk-config --cflags --libs # default: "gtk"
-I/usr/X11R6/include -I/usr/local/lib/glib/include -I/usr/local/include
-L/usr/local/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib \
-ldl -lXext -lX11 -lm
$ gnome-config --cflags --libs # default: "" ???
gnome-config should imho _at least_ default to "gnome" (if not "gnomeui"),
in case no libs are given explicitely.
also, the --libs-only-L and --libs-only-l options featured by gnome-config
should probably also be featured by gtk-config and glib-config and even
be furtherly split up into --libs-only-L, --libs-only-l, --libs-only-l-self
and --libs-only-l-system (where --libs-only-l is a superset of
--libs-only-l-self (e.g. -lglib -lgmodule -lgthread) and
--libs-only-l-system (e.g. -lpthread -ldl -lm) so we can implement
proper implementation-level-ordered chaining of the *-config scripts.
this is required especially to "demangle" the -L, -l and other -[misc]
$ gnome-config --libs gnomeui$
-rdynamic -L/usr/local/lib -L/usr/X11R6/lib -lgnomeui -lart_lgpl \
-lgdk_imlib -lSM -lICE -lgtk -lgdk -lgmodule -lXext -lX11 -lm \
-lgnome -lgnomesupport -ldb -lglib -ldl
which should better read:
-L/usr/local/lib -L/usr/X11R6/lib -rdynamic -lgnomeui -lart_lgpl \
-lgdk_imlib -lgtk -lgdk -lgnome -lgnomesupport -lgmodule -lglib \
-lSM -lICE -lXext -lX11 -ldb -ldl -lm
so in effect, we get top to bottom level ordering of the
implementation/library layers, rather than some pseudo-random mixup
(important for e.g. symbol overloading and resolving of inter-library
given that we use LIBS_PATH for -L options, LIBS_LINK_SELF for -l options
regarding the package and LIBS_LINK_SYSTEM for system library requirements,
the above output can be achived by all scripts adding to these variables
LIBS_PATH="$LIBS_PATH "`lowlevel-config --libs-only-L $remaining_libs`
LIBS_LINK_SELF="$LIBS_LINK_SELF "`lowlevel-config --libs-only-l-self $remaining_libs`
LIBS_LINK_SYSTEM="$LIBS_LINK_SYSTEM "`lowlevel-config --libs-only-l-self $remaining_libs`
and then simply output stuff along the lines of:
echo $LIBS_PATH $LIBS_LINK_SELF $LIBS_LINK_SYSTEM
also, to simplify (and correct) the above autoconf test, a
--check-version mj.mn.mc to those scripts would be nice, which would
work basically like the GTK_CHECK_VERSION(major,minor,micro) macro -
though that maybe overkill once we have proper AM_PATH_* macros all over
the un-involved might wonder why we need those *-config scripts at all, once
we got the AM_PATH_* bussiness consistently working, there are two reasons
1) `gnome-config --cflags --libs gnomeui` (or similar invokations) is really
nice to use inlined in small project Makefiles, e.g.
- for test (bug-exposure) programs,
- panel applets,
- addons like a GnomeCanvasItemWithSpecialFeature, or
- programs that don't require additional libraries besides the ones
required by gnome already and don't build own libraries, like an
imaginary gnome-oss-mixer application (dunno whether gmix depends
on ALSA yet or builds an extra library).
2) the AM_PATH_* macros simply revert to the *-config scripts (once they
figured their locations) to build up the correct *_CFLAGS and *_LIBS
> We should move toward the same scheme used by other projects like
> gtk and glib: at install time each package should stick the macros it
> provides in $prefix/share/aclocal.
> I remember there was some discussion in the past and Martin
> implemented some sort of hack to make things work, but it does not
> address the install-in-share-aclocal issue.
> Any volunteer that wants to take over this task?
hehe, nice Q, that one ;)
] [Thread Prev