Re: The autoconf macros business.

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 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]*//'`]
                AC_MSG_RESULT(found $GNOME_VERSION)
                case "$GNOME_VERSION" in
                '1.0.'*[)]      ;;
                *[)]    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


gnome-config --version
gnome-libs 1.0.6

i think gnome-config is broken in outputting the preceeding "gnome-libs " for the
--version option.

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"
-I/usr/local/lib/glib/include -I/usr/local/include
-L/usr/local/lib -lglib

$ 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]
options, e.g.

$ gnome-config --libs gnomeui$

puts out:

-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:

also, to simplify (and correct) the above autoconf test, a
--check-version 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 place.

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
for this:
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 ;)

> Miguel.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]