Re: the *-config scripts

[Tim Janik <timj gtk org>]

On 4 Jun 2000, Havoc Pennington wrote:

> 
> Martijn van Beers <martijn@earthling.net> writes:
> > 
> > I am hoping we can replace *-config with something like gnome-config
> > and *Conf.sh scripts. I asked owen on irc if this was going to
> > happen, and he said 'maybe, but I don't want to copy gnome-config
> > blindly.'
> > 
> > So I'm sending this mail to start a discussion on what the requirements
> > of the new g-config script would be.
> > 
> 
>  - written in portable sh (joy!)
>  - a way to check whether a package is installed and known about
>  - a way to get the version of each package, and perhaps 
>    support for checking that the version matches the desired
>    version
>  - a way to get the link flags of each package
>  - a way to get the compile flags
>  - should uniquify the flags (remove duplicates)
>  - should support an env variable with a search path for the Conf.sh
>    files (as with GNOME_LIBCONFIG_PATH)
>  - implemented in the near future ;-)

you're missing library ordering here. that, and a couple of the points you
mention, i already raised more than a year ago. i've appended that message.

---
ciaoTJ

Date: Sat, 10 Apr 1999 00:42:12 +0200 (CEST)
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.

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+
        AM_PATH_GTK(1.2.1,
                ,
                AC_MSG_ERROR(Cannot find GTK+ - gtk-config missing from path?)
        )
        PROJECT_CFLAGS="$GTK_CFLAGS"
        PROJECT_LIBS="$GTK_LIBS"

        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);;
                esac
                PROJECT_CFLAGS=`gnome-config --cflags gnomeui`
                PROJECT_LIBS=`gnome-config --libs gnomeui`
        else
                AC_MSG_RESULT(no)
                AC_MSG_ERROR(Cannot find GNOME - gnome-config missing from path?)
        fi
        
        AC_SUBST(PROJECT_CFLAGS)
        AC_SUBST(PROJECT_LIBS)

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
1.2.1
$ gtk-config --version
1.2.1

but:

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

but:

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

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

LIBS_PATH="$this_package_LIBS_PATH"
LIBS_PATH="$LIBS_PATH "`lowlevel-config --libs-only-L $remaining_libs`
LIBS_LINK_SELF="$this_package_LIBS_LINK_SELF"
LIBS_LINK_SELF="$LIBS_LINK_SELF "`lowlevel-config --libs-only-l-self $remaining_libs`
LIBS_LINK_SYSTEM="$this_package_LIBS_LINK_SYSTEM"
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 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
   contents.

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

---
ciaoTJ