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
