[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 13:11:29 +0700

Hi Sam, Bruno,

On 12 Oct 2010, at 08:39, Gary V. Vaughan wrote:
> 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.

Actually, this patch is quite broken.  It happily rewrites *all* _GL_
symbols for files copied to $libdir, but it doesn't fix up headers that
come from gnulib/build-aux, so *references* to macros defined there get
rewritten, but not the definitions.  Also it doesn't rewrite any of the
Makefile.am snippets from module files that rely on sed scripts keyed
to the original _GL_ symbols (e.g. the c++defs.h include machinery).

> This patch (or similar) would certainly make libposix much cleaner too.

I think that all we needed was a way of rewriting the include guards, and
that rewriting every symbol containing _GL_ is much too heavy handed.  I'm
working on a gentler version of the patch that only matches the include

Gary V. Vaughan (address@hidden)

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

reply via email to

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