Hi Ralf!
>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> 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.
