[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: double inclusion guard
From: |
Gary V. Vaughan |
Subject: |
Re: double inclusion guard |
Date: |
Tue, 12 Oct 2010 08:39:39 +0700 |
Hi Sam, Bruno,
On 12 Oct 2010, at 06:17, Bruno Haible wrote:
>>> You probably renamed the inclusion guard (_GL_STDLIB_H)
>>> appropriate (as recommended).
>>
>> does this "as recommended" mean that you are now more amenable to
>> accepting my patch?
>> http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/gnulib-tool.patch?view=log
>
> The fact that you have been testing this approach for a year and have reported
> just this one problem with it gives it some trust. Also Bruce Korb's libposix
> needs a similar treatment.
I was just homing in on a similar patch myself, after struggling to write a
post-install hook sed script that will rewrite the include guards without
accidentally catching and rewriting other random _GL_ prefixed symbols.
This patch (or similar) would certainly make libposix much cleaner too.
> But I'm wondering whether we might see different behaviours when using
> compilers
> which support #include_next and other compilers which don't. When you have two
> gnulib-generated files
>
> main/gllib/stdlib.h
> extra/gllib/stdlib.h
>
> and the compiler options include "-Iextra/gllib -Imain/gllib", then
> with compilers of the first kind the program will include
>
> extra/gllib/stdlib.h -> main/gllib/stdlib.h -> /usr/include/stdlib.h
>
> whereas with compilers of the second kind the program will include
>
> extra/gllib/stdlib.h -> /usr/include/stdlib.h
>
> Such differences would be very hard to diagnose when they lead to problems.
> Any ideas?
There are only two options to make both cases behave the same -
1. always hardcode the full path to the system header, even on machines
with include_next support;
2. teach gnulib to generate full include paths to another gnulib directory
under some circumstances (i.e. when importing to extra/glib, set an
option to write include paths that point to main/gllib.
(2) seems fragile and is more difficult to implement, so the general solution
must be to not use include_next.
Cheers,
--
Gary V. Vaughan (address@hidden)
PGP.sig
Description: This is a digitally signed message part
- error: redefinition of `struct random_data', Sam Steingold, 2010/10/11
- Re: error: redefinition of `struct random_data', Bruno Haible, 2010/10/11
- Re: error: redefinition of `struct random_data', Sam Steingold, 2010/10/11
- Re: double inclusion guard, Bruno Haible, 2010/10/11
- Re: double inclusion guard,
Gary V. Vaughan <=
- Re: double inclusion guard, Eric Blake, 2010/10/11
- Re: double inclusion guard, Gary V. Vaughan, 2010/10/11
- Re: double inclusion guard, Bruce Korb, 2010/10/12
- Re: double inclusion guard, Bruno Haible, 2010/10/12
- Re: double inclusion guard, Bruno Haible, 2010/10/12
- Re: double inclusion guard, Gary V. Vaughan, 2010/10/13
- Re: double inclusion guard, Gary V. Vaughan, 2010/10/12