Re: Reverse AC_REQUIRE and AC_CHECK_TYPE changes?

[Adam J. Richter]

Akim,

        Thank you for you response about my questions on the changes
to AC_REQUIRE and AC_CHECK_TYPE.  I had already read the documentation
that you refer to before I sent my email.  What I was looking for were
*reasons* for the change, by which I mean something other than one
person's opinion about other people's programming style.

>[AC_REQUIRE] 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.

        I've given you concrete reasons why it is useful (the macros
that other macros call are often changing and some of those macros
complain or abort if called multiple times and it slows configure
scripts, which are already slow enough to deter some people from using
autoconf).  When you have some time, I would hope you would show how
AC_REQUIRE at the top level is "dangerous" and why we cannot ensure
that AC_REQUIRE could work at the top level.  As far I could tell, it
worked before.

        Anyhow, at some point, you or someone else might want to try
to document or fix the technical problem that requires AC_REQUIRE not
to work at the top level.

        I intend the following paragraph as advice for you to
consider, rather than argument on this particular matter.  No offense
intended, but, if it may help your credbility outside of the autoconf
mailing lists to remember that "people who live in glass houses
shouldn't throw stones" when it comes to programming style.  If you
want the GNU programming culture to become something where people
actively sabotage other people's programming to enforce their
standards of style too rigidly (I know this always happens to some
tiny degree), then autoconf and m4 would be among the first things on
many people's "black lists."

>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

        I don't understand how it was "dead broken."  Can you please
just state the technical consequences of the previous syntax that you
were concerned about and let the goodness or badness of those
consequences make or fail to make the argument?  The original syntax
was much clearer for what people wanted to do most of the time, and
some program prefer macros to ifdef's.

        I do not understand how it was worth the tradeoff to use the
same name and break a lot of existing code, especially when the
failure mode that this induces is not easily detectable (autoconf will
not get an error, but rather the program might fail to compile or will
compile differently, and you have to look carefully through config.log
if you do not know what you're talking about).  It will probably be a
year before all of the code that has this problem is found and fixed.
If you want to change the semantics of AC_CHECK_TYPE, can't you at
least provide the old semantics by some public function?

        Anyhow, I appreciate your reply.  If somebody does have time
to document the actual underlying technical tradeoffs (not style
proclamations), that would be great.  Thanks again for your reply.

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