Avoiding namespace-pollution when adding gnulib modules to libltdl?

[Gary V. Vaughan]

Hi All,

I've been integrating gnulib-tool into libtool on and off for the
last few weeks, but I'm stuck when it comes to letting gnulib-tool
add modules to libltdl.

As you know `libtoolize --ltdl' puts a copy of the sources required
to build libltdl.la into a parent project... variously as a completely
independent subproject with its own configure, with a shared configure
and a recursive Makefile.am, or with an includable non-recursive make
fragment so that all the compilation takes place from top_builddir.

I've gotten stuck figuring out how to manage whatever sources and
macros gnulib-tool adds to libltdl in each of these cases. The non-
recursive libltdl option being the most problematic...

If the parent project (the one that runs libtoolize --ltdl to add
the libltdl sources to its own distribution) also uses gnulib files,
quite likely of a different revision to the ones that happen to be
distributed with that particular release of libtoolize, what's the
best way to avoid namespace clashes in the following spaces:

 - the libltdl ABI when, say, argz and its dependencies are compiled in,
   and then libltdl is loaded into the (gnulib using) parent project;
 - the filesystem when the parent project is sharing AC_CONFIG_MACRO_DIR
   and/or AC_CONFIG_AUX_DIR with libltdl (either by virtue of using a
   non-recursive build, or simply to reduce distributing multiple copies
   of macros and aux files);
 - M4, when a single configure might end up wanting to include libltdl's
   argz macro, as well as another for the parent project;
 - configure shell code after all the macros have expanded;
 - Makefile snippets from 'include ltdl/ltdl.mk' versus the parent's
   gnulib/gnulib.mk;

 ??

As best as I can see, I need to rename everything I let gnulib-tool
import into libltdl :(

  - all the externally visible C symbols (CPP makes that easy enough);
  - all the non-source files, I was hoping build-aux is stable enough
    to let the parent overwrite anything that libtoolize copies in,
    and maybe scoop up all the .m4 files into a new ltdl-gnulib.m4;
  - all the M4 symbols, I might be able to come up with a way of
    tracing all m4_define and AC_DEFUNs, discarding the ones that are
    part of autoconf, and using sed to substitute an LT_ prefix onto
    everything else;
  - the worst part will be collecting all the shell symbols from the
    unexpanded ltdl-gnulib.m4 and renaming all of those;
  - renaming all the rules and non-API variables added to ltdl.mk by
    gnulib-tool;

Even to do this by hand for just argz and its dependents seems like
a *huge* amount of work for the payoff of using gnulib's argz over
the old one still in libltdl.  And I'd hate to have to do it again
everytime I add a new module.  But coming up with a general automated
way of collecting and renaming all of these things seems prohibitive.

Is there an easier way?  Or is gnulib-tool just not the right tool for
adding modules to libltd, which as all then pulled into another project
later using libtoolize and then redistributed, quite possibly along with
that project's own overlapping set of gnulib modules?

Another option might be to simply make a policy statement that if the
parent project uses gnulib, then libltdl has to be compiled with its
own subconfigure, Makefile, build-aux and macro dirs.  But that's a
lot of extra weight, duplication of code and is an arbitrary restriction
I'd rather avoid if it can be done without too much effort.

Any pointers or clues very much appreciated.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)