[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.
/Simon
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request,
Simon Josefsson <=
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/01
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/01
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/01
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/01
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/02