[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib-tool feature request

From: Simon Josefsson
Subject: Re: gnulib-tool feature request
Date: Mon, 01 Mar 2010 21:36:42 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Sam Steingold <address@hidden> writes:

> On 2/27/10, Simon Josefsson <address@hidden> 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/address@hidden/msg14805.html
> http://www.mail-archive.com/address@hidden/msg14807.html
> http://www.mail-archive.com/address@hidden/msg14808.html
> http://www.mail-archive.com/address@hidden/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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]