autoconf
[Top][All Lists]
Advanced

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

Reverse AC_REQUIRE and AC_CHECK_TYPE changes?


From: Adam J. Richter
Subject: Reverse AC_REQUIRE and AC_CHECK_TYPE changes?
Date: Tue, 31 Jul 2001 06:03:35 -0700

        Sorry if this message is a little out of place, but I
thought it might be a good idea for me to provide a little bit
of feedback from "the trenches" of having to port a bunch of
software to autoconf-2.52.

        At the outset, let me say that I am very glad to see the
faster release cycle for autoconf these days.  Thank you very much
for that.  I would much rather put up with the changes that I'm about
to gripe about than have to wait a long time between releases and see
other programs shipped that depended on unreleased versions of autoconf,
as happened with fileutils-4.0, for example.

        Anyhow, my feedback is fairly simple: there are two changes
that I keep bumping into that tend to make a lot of work, and I
don't get the sense from the autoconf.info file that they were
really all that necessary:

        1. AC_REQUIRE cannot be called from top level.

        Now I have to write lots of little macros like:

AC_DEFUN(REQUIRE_FOO,[AC_REQUIRE(FOO)]);
AC_REQUIRE_FOO

        Calling AC_REQUIRE from the top level is extremely useful,
especially when you are dealing with a bunch of macros whose
from external packages that have definitions that are constantly
being changed, so you cannot always be certain that a particular
macro has been called.  I don't understand why you need to be
inside of an AC_DEFUN now for this.  Is it an m4 diversion issue?

        2. New AC_CHECK_TYPE format.

        In practice, programs use many more "fallback" type names
as the second parameter to AC_CHECK_TYPE, which the new code fails
to detect.  The "old" format also make for much more readable
configure.in files.  Can't we just put the new format in a separate
AC_CHECK_TYPE_NEW() macro?  It would do a lot for backward
compatability.  A second best solution, which would not maintain
backward compatability, would be to make a public interface
AC_CHECK_TYPE_OLD.

        Anyhow, I don't mean to start a flame war about this.  I just
want to to report my experiences with autoconf-2.5x, which you can
consider or ignore as you see fit.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
address@hidden     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."



reply via email to

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