Re: Reverse AC_REQUIRE and AC_CHECK_TYPE changes?

[Akim Demaille]

>>>>> "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.