Eric Blake wrote:
> the proposed patch is okay with me, as long as you verify that none of
> your changes to gl_PREREQ_* blocks cause problems.
Verified by inspection.
Jim Meyering wrote:
> Fine by me. Thanks!
Committed and pushed.
Bruno
Bruno Haible wrote:
> I'm applying the first patch below and proposing the additional 3 patches at
> the end. Jim, Eric, ok to apply?
...
> 2009-12-31 Bruno Haible
>
> Use AC_C_INLINE where necessary.
> * m4/chdir-long.m4 (gl_PREREQ_CHDIR_LONG): Require AC_C_INLINE.
>
> Use AC_
Hi Eric,
> if gl_PREREQ_whatever is changed to have no output (as you just did
> here, by changing : to AC_REQUIRE), then you created a syntax error.
Oops, you're right. I propose to use the patch below instead.
> In general, I've been starting to steer away from trivial gl_PREREQ blocks
> (th
Bruno Haible clisp.org> writes:
> AC_DEFUN([gl_PREREQ_CHDIR_LONG],
> [
> - :
> + AC_REQUIRE([AC_C_INLINE])
> ])
In general, this is dangerous. The idiom has often been:
if condition; then
gl_PREREQ_whatever
fi
which means if gl_PREREQ_whatever is changed to have no output (as you just
The following files use 'inline' but don't require AC_C_INLINE.
lib/chdir-long.c
lib/fatal-signal.c
lib/fts.c
lib/mbchar.h
lib/mbfile.h
lib/mbiter.h
lib/mbuiter.h
lib/regcomp.c
lib/regexec.c
lib/regex_internal.c
lib/regex_internal.h
lib/stat.c
lib/u64.h
lib/wait-process
