Re: double inclusion guard

[Gary V. Vaughan]

Hallo Bruno,

On 13 Oct 2010, at 02:48, Bruno Haible wrote:
>> 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.
> 
> Thanks for these thoughts, Gary and Eric.
> 
> To sum up the discussion:
> 
>  - Double inclusion guards must depende on the macro_prefix.

I was wondering whether overloading macro_prefix like this is the best
approach.  It's certainly more flexible to have --macro-prefix to specify
just the macro prefix, and a new --include-guard-prefix for include
guard rewriting... but whether that flexibility will actually be useful
I don't know.  Certainly, even though we definitely need to rewrite the
include guards for installed headers from libposix, I would have been
perfectly happy to retain the default gl_INIT macro name for libposix's
configure.ac.  And, besides, LIBPOSIX_INIT seems like a misnomer to me.

>  - gnulib-tool needs an option --base-gnulib=.../gnulib-cache.m4
>    that has two effects:
>      - It rewrites the include_next invocations for old compilers,
>        so that the program will always include
>          extra/gllib/stdlib.h -> main/gllib/stdlib.h -> /usr/include/stdlib.h
>      - It implies --avoid options for all the modules listed in the base
>        gnulib-cache.m4. (Otherwise modules get duplicated, causing malfunction
>        of modules that have global state, like sigaction, fchdir, and 
> similar.)
> 
>  - All typedefs that are defined in a .h file and are not triggered by a 
> module
>    for a function replacement must have a double definition guard, like we 
> did for
>    'struct random_data'.

This sounds like a robust and thorough approach to a tricky problem.

Do you plan to work on this reasonably soon (within a couple of weeks)?  If so,
I'll wait until the patches arrive in master, and build from there for an
improved topic/libposix that also addresses as many of your review comments
as possible.

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

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