Sam Steingold <s...@gnu.org> writes: > On 2/27/10, Simon Josefsson <si...@josefsson.org> wrote: >> >> > Since I use gnulib in several sub-modules, I need to avoid conflicts >> >> > between different gnulib imports. >> >> > thus I need to make all those _GL_* constants module-specific. >> >> > thus I need gnulib-tool to accept a --macro-prefix option and this >> patch: >> >> >> >> I believe the recommended way to avoid conflicts between different >> >> gnulib imports is to use a separate configure.ac for each gnulib import, >> > >> > of course I have a separate configure.in for each module! >> > the setup works just fine, I just don't want to have to apply the >> > patch to gnulib-too myself each time I pull from gnulib. >> >> Then I don't understand what purpose the patch serves? Each >> configure.in instance should have its own namespace? > > The sub-modules have to share the gnulib directories > (so that they do not include several identical object files)
I don't follow here. I use separate configure.ac (for example in GnuTLS), with separate gnulib directories for each configure.ac. So sub-modules do not _have_ to share gnulib directories. Can't you use a separate gnulib directory for each configure.ac? Then there are no header file collisions. Yes, some object files will be duplicated, but that isn't harmful. > which results in header conflict: each gllib directory contains > its own (e.g.) unistd.h which is adapted to the specific submodule. > therefore if all these headers use the same _GL_UNISTD_H macros, > the wrong gllib header is used, the wrong functions are declared, > the wrong system headers are included and nothing works. Right, that will not work well. > This has been discussed on this list in the thread > "uname: build problem on win32" in August 2009. > See > http://www.mail-archive.com/bug-gnulib@gnu.org/msg14805.html > http://www.mail-archive.com/bug-gnulib@gnu.org/msg14807.html > http://www.mail-archive.com/bug-gnulib@gnu.org/msg14808.html > http://www.mail-archive.com/bug-gnulib@gnu.org/msg14814.html > > At that time, Bruno said that "for now, this change is better limited > to your project." > I think that now, after several months of testing in clisp, > the time is ripe to include the change in gnulib. I don't really understand this, so I'll leave it to others to review. /Simon
