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 guards. Cheers, -- Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
