bug-gnulib
[Top][All Lists]
Advanced

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

Re: [Bug-gnulib] Re: getline AC_LIBOBJs


From: Bruno Haible
Subject: Re: [Bug-gnulib] Re: getline AC_LIBOBJs
Date: Fri, 24 Oct 2003 14:02:35 +0200
User-agent: KMail/1.5

Paul Eggert wrote:
> I installed this more-conservative-but-uglier patch instead.
>
>       * getline.m4 (AM_FUNC_GETLINE):
>       Don't include getndelim2.o twice into LIBOBJS; this breaks on some
>       hosts.  Problem reported by Derek Robert Price in
>       <http://mail.gnu.org/archive/html/bug-gnulib/2003-10/msg00092.html>.
>       This patch can be withdrawn after Autoconf 2.58 is required for gnulib.
>       * getndelim2.m4 (gl_GETNDELIM2): Likewise.

Thanks! Looks fine to me.

> Maybe this is a symptom of a more general problem?  Should coreutils
> be saying just "gl_FOO" rather than AC_REQUIRE([gl_FOO])?  (I wish
> these dependency issues weren't so confusing!)

Good question. Since the general question in autoconf cannot be easily
resolved (see
http://mail.gnu.org/archive/html/bug-gnulib/2003-04/msg00027.html),
maybe we should document for each macro whether it is AC_REQUIREable
or not. If it is, then it must not be used inside shell 'if'. If it
is not, then it must not be AC_REQUIREd. So it boils down to a documentation
issue.

The entry point to gnulib modules should IMO be AC_REQUIREable. It
allows grouping the calls together without caring for duplicates and
without bloating the configure file.
E.g. if I have a lib/ and a src/ directory, and both rely on <stdbool.h>,
then I want to me able to create a
   my-lib.m4    invoking   AC_REQUIRE([gl_STDBOOL])
   my-src.m4    invoking   AC_REQUIRE([gl_STDBOOL])  as well
and configure.ac invokes both. This should not lead to two copies
of the shell code in the configure file.

The rationale for this is that it's rare to _conditionally_ need a
gnulib macro.


More generally, every gnulib module that needs it could have two entry
points, gl_FOO_REQUIREABLE and gl_FOO_NONREQUIREABLE, that could be
implemented using the following pattern:


dnl Can be REQUIREd but not be used inside if.
AC_DEFUN([gl_FOO_REQUIREABLE]. [gl_FOO_NONREQUIREABLE])

dnl Can be used inside if. Can also be invoked multiple times.
AC_DEFUN([gl_FOO_NONREQUIREABLE], [
  if test -z "$foo_done"; then
    foo_done=yes
    gl_FOO_GUTS
  fi
])

dnl Undocumented, not an entry point.
AC_DEFUN([gl_FOO_GUTS], [...Here comes the shell code...])


Now one can even create a macro AC_DEFUN_TWICE, in such a way that all
the code above is expanded from

  AC_DEFUN_TWICE([gl_FOO_REQUIREABLE]. [gl_FOO_NONREQUIREABLE],
    [...Here comes the shell code...])


Bruno





reply via email to

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