Re: proposed support for C1X-style static_assert

On 05/22/11 16:09, Bruno Haible wrote: > "verify.h" no longer defines the 'verify' macro if > was already included in the same compilation unit. Thanks, I pushed this fix: verify: fix bug when gnulib is also included * lib/verify.h (verify, verify_true): Define if _GL_VERIFY_H is defined, not i

Re: proposed support for C1X-style static_assert

Hi Paul, > Here's what I pushed. Thanks to Bruno and Eric for the reviews. > > --- > ChangeLog | 22 +++ > doc/posix-headers/assert.texi | 21 ++- > lib/assert.in.h | 28 + > lib/verify.h | 130 >

Re: conditional dependencies between modules

Hi Ralf, > If this bug is still apparent in some way or other, I'd appreciate a > report on bug-automake with a recipe for reproduction. Thanks for the reminder. I have reported it now at

Re: flymake support in gnulib

* Reuben Thomas wrote on Sun, May 22, 2011 at 06:48:16PM CEST: > Until the GNU build system > abandons portable make (I wish it would!), we should be sticking to > portable makefiles, which after all do have real advantages. Even if the GNU build system aims to support portable make, that doesn't

Re: include_next fails on cross-compiling

Hi John, > Cross compiling to host=i586-mingw32msvc I encountered 2 problems related to > include_next.m4. > > Firstly I had to apply the attached patch to avoid configure complaining > about missing operands. > > Secondly, I had to put gl_INCLUDE_NEXT in configure.ac which I was rather >

include_next fails on cross-compiling

Cross compiling to host=i586-mingw32msvc I encountered 2 problems related to include_next.m4. Firstly I had to apply the attached patch to avoid configure complaining about missing operands. Secondly, I had to put gl_INCLUDE_NEXT in configure.ac which I was rather surprised about. Since it

Re: flymake support in gnulib

On 22 May 2011 14:34, Ralf Wildenhues wrote: > > Why should this rule not be accepted by automake?  Just turn off the > warning about non-portable make constructs. I think that would be a mistake for two reasons: first, the rule I'm proposing is a maintainer rule, and it's better to make it avail

Re: xgetcwd.m4 simplification

Bruno Haible wrote: > And another one here: 'xgetcwd' depends on 'getcwd' already. > > > 2011-05-22 Bruno Haible > > xgetcwd: Simplify autoconf macro. > * m4/xgetcwd.m4 (gl_XGETCWD): Don't require gl_FUNC_GETCWD. > > --- m4/xgetcwd.m4.origSun May 22 17:29:23 2011 > +++ m4/xge

xgetcwd.m4 simplification

And another one here: 'xgetcwd' depends on 'getcwd' already. 2011-05-22 Bruno Haible xgetcwd: Simplify autoconf macro. * m4/xgetcwd.m4 (gl_XGETCWD): Don't require gl_FUNC_GETCWD. --- m4/xgetcwd.m4.orig Sun May 22 17:29:23 2011 +++ m4/xgetcwd.m4 Sun May 22 17:28:40 2011

new module 'mktime-internal'

The m4/timegm.m4 macro makes use of lib/mktime.c in unexpected ways: It uses it to define a function mktime_internal(). It sits in the wrong .m4 file, leading to maintenance bugs like the one I just found. Additionally, it has a bug: It tests for a __mktime_internal function in libc and then goes

timegm: complete an old fix

On 2009-07-28, we changed to use the C++ safe idioms for 'mktime': But not completely: I missed that the logic of replacing mktime is duplicated in m4/timegm.m4

Re: flymake support in gnulib

Hi Reuben, * Reuben Thomas wrote on Fri, May 20, 2011 at 11:32:29PM CEST: > I've just been playing with flymake. To make it work at all I copied > the following rule into my src/Makefile.am from the flymake manual: > > check-syntax: > gcc -o nul -S ${CHK_SOURCES} > > It would be nice to pu

Re: conditional dependencies between modules

Hi Bruno, * Bruno Haible wrote on Tue, Apr 26, 2011 at 02:27:52AM CEST: > Here's an experimental patch that allow conditional dependencies between > modules. > If you get an error like > gllib/Makefile.am:137: GL_GENERATE_STDDEF_H does not appear in > AM_CONDITIONAL > it is a symptom of a bug

timegm.m4 simplification

Hi Paul, Jim, > True. Good change. That's obviously correct. A similar one is here. 'timegm' depends on 'time_r' as a module, therefore I'm applying this: 2011-05-22 Bruno Haible timegm: Simplify autoconf macro. * m4/timegm.m4 (gl_PREREQ_TIMEGM): Don't require gl_TIME_R.