bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inline cleanup, part 3


From: Eric Blake
Subject: Re: inline cleanup, part 3
Date: Thu, 31 Dec 2009 16:08:04 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Bruno Haible <bruno <at> 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 did 
here, by changing : to AC_REQUIRE), then you created a syntax error.  
Fortunately, for this particular test, it worked, since gl_PREREQ_CHDIR_LONG 
was used alongside AC_LIBOBJ inside the same if/fi block.

In general, I've been starting to steer away from trivial gl_PREREQ blocks 
(those with only : or AC_REQUIRE).  If I understand correctly, they were 
originally developed to help minimize redundancy and avoid expand-before-use 
problems in configure.ac, back in the days before we figured out how to 
reliably use AC_PREREQ, and before the creation of a reliable AC_DEFUN_ONCE.  
So it is just as easy to inline the AC_REQUIRE to the call-site, and simplify 
the .m4 files to have fewer macros, where that works.

But yes, the proposed patch is okay with me, as long as you verify that none of 
your changes to gl_PREREQ_* blocks cause problems.

-- 
Eric Blake






reply via email to

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