[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reverse AC_REQUIRE and AC_CHECK_TYPE changes?
From: |
Akim Demaille |
Subject: |
Re: Reverse AC_REQUIRE and AC_CHECK_TYPE changes? |
Date: |
01 Aug 2001 20:26:16 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) |
>>>>> "Adam" == Adam J Richter <address@hidden> writes:
Adam> At the outset, let me say that I am very glad to see the faster
Adam> release cycle for autoconf these days.
So are we! I think I stopped losing hair, and it might even be
growing back!
Adam> Anyhow, my feedback is fairly simple: there are two changes
Adam> that I keep bumping into that tend to make a lot of work, and I
Adam> don't get the sense from the autoconf.info file that they were
Adam> really all that necessary:
Adam> 1. AC_REQUIRE cannot be called from top level.
It will not change. Never. Because it makes no sense, and is
dangerous. I might detail in the documentation why we can't ensure
the REQUIRE semantics at the top level, but I won't try to make it
work.
Adam> Now I have to write lots of little macros like:
Adam> AC_DEFUN(REQUIRE_FOO,[AC_REQUIRE(FOO)]); AC_REQUIRE_FOO
Why? Just run FOO.
Adam> Calling AC_REQUIRE from the top level is extremely useful,
Adam> especially when you are dealing with a bunch of macros whose
Adam> from external packages that have definitions that are constantly
Adam> being changed, so you cannot always be certain that a particular
Adam> macro has been called. I don't understand why you need to be
Adam> inside of an AC_DEFUN now for this. Is it an m4 diversion
Adam> issue?
Yes/no. Yes/no. Actually yet the documentation contains some hints.
| `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 should just run FOO. Don't try to play tricks, you'll pay
someday.
Adam> 2. New AC_CHECK_TYPE format.
Adam> In practice, programs use many more "fallback" type names as
Adam> the second parameter to AC_CHECK_TYPE, which the new code fails
Adam> to detect. The "old" format also make for much more readable
Adam> configure.in files.
But it's dead broken. The right means to replace a type is using
typedef. You ought to have a system.h with something like
#if !HAVE_SIZE_T
typedef unsigned int size_t;
#endif
We are moving slowly towards autosystem, which will create this for
you, but the old behavior will gradually be obsoleted.
Adam> Can't we just put the new format in a separate
Adam> AC_CHECK_TYPE_NEW() macro?
As often as I can I will use the `right' names for the right macros.
Too bad, AC_CHECK_TYPES is exactly the right name, but its body was
junkie. Hence the heuristics.
Adam> It would do a lot for backward compatability.
I don't want to clutter the future with past misdesigns. Today
AC_CHECK_* has a standard interface, and I'm proud of it. I won't ask
users to remember some of the AC_CHECK_* members have a _NEW behind.
Adam> A second best solution, which would not maintain backward
Adam> compatability, would be to make a public interface
Adam> AC_CHECK_TYPE_OLD.
The only thing we will do to help you on this one is adjusting the
heuristics to actual cases. Please, report where it is wrong.
Adam> Anyhow, I don't mean to start a flame war about this.
Good :)
Adam> I just want to to report my experiences with autoconf-2.5x,
Adam> which you can consider or ignore as you see fit.
We are of course interested! But we also are guilty of not having
_explained_ some of the changes.
I hope my explanations convinced you.
- Re: Reverse AC_REQUIRE and AC_CHECK_TYPE changes?,
Akim Demaille <=