Re: The autoconf macros business.

[James Henstridge <james daa com au>]

A while back I was looking at the problem with all the <package>-config
scripts, and how to handle working out the CFLAGS and LIBS for
combinations of different packages.  I came up with the idea of having a
single pkg-config script that reads config files that would be installed
by the various packages.

The config files installed by each package would be standard shell scripts
that would be source'd.  They would have to set the variables CFLAGS,
LIBS and REQUIRES.  The pkg-config script would read these files, resolve
dependencies between packages, remove duplicate flags and output the
values for cflags or libs.

So the config file for gnomeui may look like this:
  # this value would probably be set by the configure script:
  prefix=/usr/local
  REQUIRES="gnome gdk_imlib gtk SM db"
  CFLAGS="-I${prefix}/include"
  LIBS="-L${prefix}/lib -lgnomeui"


The idea is if you did
  pkg-config --libs gnomeui zvt
you would get the libs flags for a program that required gnomeui and zvt
(so it would automatically include flags for gnome, gtk+, glib and
gmodule).

The current implementation does not have any support for version checks,
but this could be added.  The problem with this is that it may break
backward compatibility.   To minimise this, I also made it so that it
checks the name it was called as and implicitely adds that package to the
list (eg if you symlink pkg-config to gtk-config, it would add gtk to the
list of required packages when run).

If anyone is interested in this sort of script, I can put it up in my FTP
site.

James Henstridge.

--
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/


On Sat, 10 Apr 1999, Tim Janik wrote:

> 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
> 
> 
> 
> -- 
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
>