[Bug-gnulib] Re: gnulib in libraries and applications

[Bruno Haible]

Simon Josefsson wrote:
> Currently, gnulib-tool doesn't support two gnulib directories in one
> project without having two different configure.ac (which is what I use
> in gsasl), so because I had gl_LGPL in configure.ac, importing the
> exit module failed.

Really, when a package installs a library and an application, I would
recommend to have two configure.ac files.
  - It avoids using GPLed code in the library inadvertently.
  - It clarifies the package structure.
  - It's just cleaner.

The only tricky thing is how to propagate the "configure --help" output
from the sub-configures to the main configure file. In gettext I found the
need to do the following:

dnl Optional Features: AC_ARG_ENABLE calls
dnl Optional Packages: AC_ARG_WITH calls
dnl Some influential environment variables: AC_ARG_VAR calls
esyscmd([{ cd autoconf-lib-link && autoconf 
--trace=AC_ARG_ENABLE:'$n([$1],[$2])' --trace=AC_ARG_WITH:'$n([$1],[$2])' 
--trace=AC_ARG_VAR:'$n($@)' && cd ..; \
           cd gettext-runtime && autoconf --trace=AC_ARG_ENABLE:'$n([$1],[$2])' 
--trace=AC_ARG_WITH:'$n([$1],[$2])' --trace=AC_ARG_VAR:'$n($@)' && cd ..; \
           cd gettext-tools && autoconf --trace=AC_ARG_ENABLE:'$n([$1],[$2])' 
--trace=AC_ARG_WITH:'$n([$1],[$2])' --trace=AC_ARG_VAR:'$n($@)' && cd ..; } \
  | sed -e 's|.AC_ENABLE_SHARED_DEFAULT.|yes|g' -e 
's|.AC_ENABLE_STATIC_DEFAULT.|yes|g' -e 
's|.AC_ENABLE_FAST_INSTALL_DEFAULT.|yes|g'])

> Running two configure.ac is really
> slow, and causes other problems as well (like generating two config.h
> files -- sometimes you need settings from two config.h...).

Actually I find it more comfortable to have two config.h: Then I know that
application changes cannot cause my library build to break.

> Sigh, I liked this idea, but it wouldn't work.  The reason is that
> many gnulib modules use AC_REPLACE_FUNCS, so you can't have more than
> one directory that use @LTLIBOBJS@ without adding the same file to
> every such directory.

There is no problem with having the same .c and .o files being added to
both the library's gnulib and the application's gnulib. They will be
compiled twice, sure, but when linking the application, it doesn't matter:
  - If in the application's link command line, the library comes before
    the application's gnulib, the modules from the application's gnulib
    will be ignored. Fine.
  - Otherwise, if the library was built statically, the modules from the
    library's gnulib will be ignored. Fine.
  - Otherwise, if the library was built shared, the duplicated modules
    will be both in the shared library and the application. That's wasted,
    but still not a compilation error. (On MacOS X, you get a warning
    for this. Oh well.)

However, there is an optimization that "gnulib-tool --import" could do:
If you could specify a set of modules which can be assumed to be
implicitly present (say, an option --omit), then gnulib-tool could omit
from the application's gnulib those modules which are already contained
in the library's gnulib:

  gnulib-tool --import --dir=lgl ...
  gnulib-tool --import --dir=gl --omit="`list-modules gl`" ...

Bruno