Re: gnulib-tool: new option --makefile-name

[Eric Blake]

Bruno Haible <bruno <at> clisp.org> writes:

> 
> While doing the coreutils changes, Paul found the answer to the long-standing
> question how gnulib-tool could be used without requiring a lib/ directory of
> its own and while still maintaining a clear separation between hand-maintained
> files and autogenerated files. Namely, rename the gnulib Makefile.am to some
> other name and include it from the real Makefile.am.
> 
> This patch adds an option --makefile-name that does this.

There are still issues if you want multiple gnulib libraries in a single 
project.  Right now, cvs M4 bootstrap uses "gnulib-tool --update" for a giant 
library used by all m4 dynamic modules, then hand-picks a smaller set of 
modules using "gnulib-tool --extract*" that are only needed when linking the 
final executable (for now, getopt and version-etc-fsf, since they provide 
interfaces that main needs but not m4 dynamic modules).

I was interested in trying out the new config-h module.  But it only works when 
using gnulib-tool --import/--update; the sed expression is not applied for 
files copied manually using --extract* information.  So next I tried tried 
experimenting with using two invocations of gnulib-tool --import to create two 
separate libraries.

My first attempt was to use gnulib-tool --makefile-name to stick both gnulib 
libraries in the same --source-base dir, but with different --makefile-name, 
different --m4-base (required, so that the two caches of which modules belong 
in which libraries are separate) and different --macro-prefix (required, so 
that configure.ac can invoke the *_EARLY and *_INIT macros of both libraries), 
and have a single glue Makefile.am pull in both makefile fragments.  This 
failed because of all the automake targets that are defined with = instead of 
+=, so the second fragment caused automake errors for all its redefinitions.

Next, I tried different --source-base dirs.  With separate imports, this almost 
works (although I found that some modules, like unlocked-io and config-h, must 
be --imported into both libraries).  The problem comes when doing "gnulib-tool -
-update" in the bootstrap script - gnulib-tool correctly determined that there 
were two gnulib-cache files and two libraries to update, but when updating the 
second library, func_import used stale --source-base and --macro-prefix values 
remembered from the first library rather than the correct values from the 
second cache.  I suppose I could rewrite m4's bootstrap to do "gnulib-tool --m4-
base=base1 --import; gnulib-tool --m4-base=base2 --import" instead of "gnulib-
tool --update", but it seems like something that gnulib-tool should be able to 
support, especially since it already detects both caches.

-- 
Eric Blake