Re: release Autoconf?

[Akim Demaille]

Hi Ralf!

>>>>> "Ralf" == Ralf Corsepius <address@hidden> writes:

Steven> Yes, I was kind of assuming that the immediate bug-patch queue
Steven> would be flushed first.  The above patch (using AC_REQUIRE
Steven> instead of calling a macro directly) seems correct, simple,
Steven> and safe.

>> Nope, I don't think this patch is right.  Do not forget that
>> AC_REQUIRE is invalid at the top level,

Ralf> I do not understand. Why is this invalid?

Here is the documentation.  The example is dead stupid, I'm interested
in any better idea.

| Prerequisite Macros
| -------------------
| 
|    A macro that you write might need to use values that have previously
| been computed by other macros.  For example, `AC_DECL_YYTEXT' examines
| the output of `flex' or `lex', so it depends on `AC_PROG_LEX' having
| been called first to set the shell variable `LEX'.
| 
|    Rather than forcing the user of the macros to keep track of the
| dependencies between them, you can use the `AC_REQUIRE' macro to do it
| automatically.  `AC_REQUIRE' can ensure that a macro is only called if
| it is needed, and only called once.
| 
|  - Macro: AC_REQUIRE (MACRO-NAME)
|      If the M4 macro MACRO-NAME has not already been called, call it
|      (without any arguments).  Make sure to quote MACRO-NAME with
|      square brackets.  MACRO-NAME must have been defined using
|      `AC_DEFUN' or else contain a call to `AC_PROVIDE' to indicate that
|      it has been called.
| 
|      `AC_REQUIRE' must be used inside an `AC_DEFUN''d macro; it must
|      not be called from the top level.
| 
|    `AC_REQUIRE' is often misunderstood.  It really implements
| dependencies between macros in the sense that if one macro depends upon
| another, the latter will be expanded _before_ the body of the former.
| In particular, `AC_REQUIRE(FOO)' is not replaced with the body of
| `FOO'.  For instance, this definition of macros:
| 
|      AC_DEFUN([TRAVOLTA],
|      [test "$body_temparature_in_celsius" -gt "38" &&
|        dance_floor=occupied])
|      AC_DEFUN([NEWTON_JOHN],
|      [test "$hair_style" = "curly" &&
|        dance_floor=occupied])
|      
|      AC_DEFUN([RESERVE_DANCE_FLOOR],
|      [if date | grep '^Sat.*pm' >/dev/null 2>&1; then
|        AC_REQUIRE([TRAVOLTA])
|        AC_REQUIRE([NEWTON_JOHN])
|      fi])
| 
| with this `configure.ac'
| 
|      AC_INIT
|      RESERVE_DANCE_FLOOR
|      if test "$dance_floor" = occupied; then
|        AC_MSG_ERROR([cannot pick up here, let's move])
|      fi
| 
| will not leave you with a better chance to meet a kindred soul at other
| times than Saturday night since it expands into:
| 
|      test "$body_temperature_in_Celsius" -gt "38" &&
|        dance_floor=occupied
|      test "$hair_style" = "curly" &&
|        dance_floor=occupied
|      fi
|      if date | grep '^Sat.*pm' >/dev/null 2>&1; then
|      
|      
|      fi
| 
|    This behavior was chosen on purpose: (i) it prevents messages in
| required macros from interrupting the messages in the requiring macros;
| (ii) it avoids bad surprises when shell conditionals are used, as in:
| 
|      if ...; then
|        AC_REQUIRE([SOME_CHECK])
|      fi
|      ...
|      SOME_CHECK
| 
|    You are encouraged to put all `AC_REQUIRE's at the beginning of a
| macro.  You can use `dnl' to avoid the empty lines they leave.


Both from the point of view of the implementation (the top level is
_really_ different), and from the semantical point of view, AC_REQUIRE
does not make sense at the top level.


Ralf> All this patch does is to require a another macro from inside
Ralf> another _standard_ macro. IMHO, if _this_ is invalid, something
Ralf> is _really_ broken in the State of Autoconf.

What you describe is valid, I agree.  But read again, I referred to
autoupdate.  If you AU define a macro then the body must be usable at
the top level, and in particular AC_REQUIRE is wrong here.

>> My holding the release is mainly due to the fact that there is a
>> problem reported by Daniel Carroll, related to AC_PROG_CPP.  Until
>> this is absolutely fixed, I don't think it is sane to release
>> Autoconf.

Ralf> FWIW: I am also seeing random problems related to AC_PROG_CPP
Ralf> (AC_PROG_CPP picking up /lib/cpp if using a cross-compiler,
Ralf> sometimes I see AC_PROG_CPP being invoked twice). Unfortunately
Ralf> I am currently not able to deterministically reproduce them nor
Ralf> do I have isolated examples.

Yes, I really think there are problems there.  We need to strengthen
the test suite too.  This is a show stopper.