[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (wishlist) Automated lib-config script generation
From: |
Tim Van Holder |
Subject: |
Re: (wishlist) Automated lib-config script generation |
Date: |
Sun, 22 Jul 2001 18:22:58 +0200 |
> Nowadays, many shared libraries include a -config script e.g. libgtk
> has a gtk-config script, and a companion m4 macro AM_PATH_GTK. The
> header also has version information embedded in it, as does the
> library itself:
>
> #define <LIB>_MAJOR_VERSION (@<LIB>_MAJOR_VERSION@)
> #define <LIB>_MINOR_VERSION (@<LIB>_MINOR_VERSION@)
> #define <LIB>_MICRO_VERSION (@<LIB>_MICRO_VERSION@)
> #define <LIB>_CURRENT_INTERFACE (@<LIB>_CURRENT_INTERFACE@)
> #define <LIB>_BINARY_AGE (@<LIB>_BINARY_AGE@)
> #define <LIB>_INTERFACE_AGE (@<LIB>_INTERFACE_AGE@)
> #define <LIB>_CHECK_VERSION(major,minor,micro) \
> (<LIB>_MAJOR_VERSION > (major) || \
> (<LIB>_MAJOR_VERSION == (major) && <LIB>_MINOR_VERSION >
> #(minor)) || \
> (<LIB>_MAJOR_VERSION == (major) && <LIB>_MINOR_VERSION ==
> #(minor) && \
> <LIB>_MICRO_VERSION >= (micro)))
>
> There is much duplication of code here. Anyone wishing to use this
> scheme must duplicate the script and then amend it for their use, and
> also convert the m4 macro as well, to AM_PATH_<LIB>. libtool could be
> used to automate this. Currently I maintain the gimp-print build
It seems to me this really is something that would fall under autoconf's
jurisdiction, so I've CC'd that list.
> scripts, and have AM_PATH_GIMPPRINT and gimpprint-config based on the
> gtk equivalents.
>
> To remove the need for m4 macro duplication, a single macro could be
> used instead. E.g.:
>
> AC_PATH_LIB(libname, minimum_version, header, config-script)
> where libname is the name of the library to check for e.g. gtk, gimp.
> minimum version is the lowest version to allow
> header is the header to include when compiling the test program
> (default libname/libname.h)
> script is the config script to run (default libname-config)
This seems potentially useful, though it would depend on how compatible
<lib>-config scripts actually are (i.e. if gtk-config and sdl-config,
for example, were to take different options, the usefulness of this
macro would be limited at best).
> Duplication of the config scripts is unavoidable, as information such
> as library location, libraries to link against, and header locations
> are hard-coded into them. However, an m4 macro could be used to
> generate them. E.g.:
>
> AC_LIB_CONFIG(libname, location)
> this would generate the script libname-config in the specified
> location in the source tree. The following variables would be used in
That should be be AC_CONFIG_LIBCONFIG, to match the existing
AC_CONFIG_* macros. I'm not sure this has to be a specific macro though,
as it could be easily created using the existing config.status mechanism.
> generating the file:
>
> <LIB>_MAJOR_VERSION
> <LIB>_MINOR_VERSION
> <LIB>_MICRO_VERSION
> <LIB>_CURRENT_INTERFACE
> <LIB>_BINARY_AGE
> <LIB>_INTERFACE_AGE
>
> <LIB>_DEFAULT_VERSION (default minimum_version)
> <lib>_cflags (clags with -I$(prefix)/include etc.
> <lib>_libs (libs with -L$(prefix/lib) and also -llibname
> and other libraries the library depends upon)
> Some of these could also be determined automatically if no variable is
> defined, except for the library dependencies. The macro could contain
> a generic config script which it parses with sed (or generates a .in
> version of the script, which is then processed by config.status).
> The script could be installed with a bin_SCRIPTS directive to
> automake.
>
> I'm not sure if an m4 macro is the most appropriate way to do this.
> Another way would be to have an LTSCRIPTS automake primary e.g.
> bin_LTSCRIPTS=libname-config, although this is probably not as good.
It's really up to the maintainer of the package what to do with the
file once it's created; adding it to bin_SCRIPTS makes sense, but the
autotools should not force such a rule.