Re: (wishlist) Automated lib-config script generation

[Tim Van Holder]

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