filemode: Fix double-inclusion guard

The macro FILEMODE_H_ is not defined anywhere. The purpose of testing it in filemode.h was therefore most probably a double-inclusion guard. 2023-04-14 Bruno Haible filemode: Fix double-inclusion guard. * lib/filemode.h: Make the double-inclusion guard actually work. diff

Re: double inclusion guard

As a followup to I am applying one of the three necessary patches, from It's the least

Re: double inclusion guard

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

Re: double inclusion guard

Hi Bruce, Gary, Bruce Korb wrote: > KISS: once you've included a gnulib mumble.h, all other > gnulib mumble.h-es are noop-ed. Nope. We cannot do this, we don't want this. It would mean that every gnulib- derived file would provide the same macros and functions. This is not compatible with gnuli

Re: double inclusion guard

Hi Gary, > 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 t

Re: double inclusion guard

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 m

Re: double inclusion guard

On 10/11/10 20:18, Gary V. Vaughan 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 > file

Re: double inclusion guard

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 n

Re: double inclusion guard

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 M

Re: double inclusion guard

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/clis

Re: double inclusion guard

Hi Sam, > > 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 hav