Support for or help with multiple gnulib instances

[rrthomas]

bootstrap doesn't seem to support multiple instances of gnulib. I guess it's relatively rare? Still, it would be good to document the expectations for this case; for example, does one use bootstrap for one installation, and handle the others manually, and are there any caveats?

[gvvaughan]

I have definitely done exactly this in the past, building one gnulib for the library, and a separate gnulib with different modules for the frontend that loads that library. I don't remember what project it was for, but it was what inspired me to write a much more configurable bootstrap script. Maybe one of the branches of GNU m4?

If memory serves, all that was required was overriding some of the driver functions at the top of the call stack from bootstrap.conf.

I wish I could be more specific and helpful!

[rrthomas]

My solution:

# paper_src_gnulib
# ----------------
# Run gnulib-tool in src/
paper_src_gnulib ()
{
    gnulib-tool --import --libtool --lib=libgnupaper \
                --source-base=src/libgnu --m4-base=src/m4 --macro-prefix=gl_paper \
                --makefile-name=Makefile.gnulib \
                relocatable-prog xvasprintf progname stdbool locale
}

func_add_hook func_gnulib_tool paper_src_gnulib

But this is hardly elegant!

[gvvaughan]

What about hooking func_reconfigure with a custom function that saves old values you want to restore after tweaking them and calling func_gnulib_tool a second time with those temporarily adjusted values?

[rrthomas]

So I guess the question would be, what are the values I need to save? Would it be just those values I need to set for the second gnulib-tool invocation? Also, why wouldn't I just hook func_gnulib_tool, with a hook function that first calls func_remove_hook so that it doesn't cause infinite recursion?

[gvvaughan]

No you’re right, once the first call is done, you can just overwrite the module list and any others you need to tweak for the second call as long as the old values aren’t needed any longer by other functions.

Hooking func_gnulib_tool is a fine solution too. It’s a flexible enough system that you can interject code wherever it’s most convenient/maintainable before it runs :-)

[rrthomas]

I guess the problem I'm having is that I don't really see what I win out of any of this hooking in different ways, as whatever I do will be different from the main gnulib: the way I've already done it doesn't seem better or worse than the other ways we've come up with. If I could configure another gnulib in the same way, it would seem more worth the effort.

[gvvaughan]

Then why not write wrappers or even an outright replacement for func_gnulib_tool that can be called/hooked once each for the two gnulibs you need, each time with different top-level configuration variables and/or module lists?

I think the callable-with-different-configurations version of func_gnulib_tool would make a fine pull request for future use, too!

[rrthomas]

Right now I've had enough! But if we've got a design, could you possibly summarise it below and leave this issue? It's the sort of thing I can easily imagine coming back to.