Re: double inclusion guard

[Gary V. Vaughan]

Hi Eric,

On 12 Oct 2010, at 08:54, Eric Blake wrote:
> On 10/11/2010 07:39 PM, Gary V. Vaughan wrote:
>> 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;
> 
> (1) is not viable.  If a system header itself uses include_next, then we MUST 
> include that header via system_include, or the nested include_next tries to 
> include the same absolute name (itself) instead of its intended target.  
> That's why we had to start using include_next throughout gnulib in the first 
> place.

Yuck :(

Then I believe the only viable option to provide stable support for multiple 
gnulib directories in a single tree is to add a switch to gnulib-tool to 
rewrite gnulib #include_next lines on import, so that both types of compilers 
include header files in the same order.  It's certainly doable, but it's going 
to be finicky and easy to break.

I believe this is the problem Bruce was thinking about (and which I dismissed 
prematurely.. sorry Bruce!) with symbols in installed gnulib headers from 
libposix clashing with non-libposix gnulib headers in a gnulib client project 
that also uses libposix... perhaps more patches like Bruno's patch from earlier 
in this thread will also be required.

Cheers,
-- 
Gary V. Vaughan (address@hidden)

PGP.sig
Description: This is a digitally signed message part