Re: Reverse AC_REQUIRE changes?

[Akim Demaille]

>>>>> "Adam" == Adam J Richter <address@hidden> writes:

Adam> I had already read the documentation that you refer to before I
Adam> sent my email. What I was looking for were *reasons* for the
Adam> change,

Sorry, I really thought it motivated the current behavior.  But more
is probably needed.



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

Adam> I've given you concrete reasons why it is useful

I've explained that AC_REQUIRE will not change, but also that if you
specify your problem, we would look for a solution.  AC_REQUIRE is
not, that's my only point.

If you are willing to use something alike, use m4_expand_once.


Adam> When you have some time, I would hope you would show how
Adam> AC_REQUIRE at the top level is "dangerous" and 

Well, the example I gave did demonstrate that it is not the same
semantics.

Adam> why we cannot ensure that AC_REQUIRE could work at the top
Adam> level.  

Read m4sugar.m4, `8. Defining macros with bells and whistles',
it pretty much explains the gory details.

Adam> As far I could tell, it worked before.

No, AC_REQUIRE was broken.  But when it has been fixed, the
possibility to use AC_REQUIRE from the top level ceased to work.  I
tried to reestablish it, and wasted hours on it, without ever getting
something functioning, and *robust*.

The semantics are different, the implementation knows that and won't
let you do it :).


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

I understand what you mean, and no offense was taken.  But I'm here to
keep Autoconf working, and I already don't have enough time to keep up
with all the requests.  So, indeed, and I do understand this is
frustrating for you and bad from me, I usually answer shortly (which
can sound harsh, but I apologize then, that's not my intend), without
much details, especially when the debate occurred more than one year
ago to finally end up as you see it today.

I try to have the documentation keep a track of the debate, technical
motivations etc. but I agree more would be needed.  I just don't have
time enough.

IMHO, you probably don't fully realize how Autoconf is fragile to
users' dirty tricks.  Users don't think they are doing tricks, and I
am certainly not blaming them: Autoconf is not providing everything
everybody needs that's for sure.

But what results is something which is extremely fragile.  Cf Automake
and Libtool trying to redefine AC_PROG_CC etc.

I will constantly add new errors where these can help us maintain a
better Autoconf, i.e., when it will help users detecting sooner the
errors they are introducing (most of the time they are hard to
discover).

But conversely that also means introducing a robust means for the
users to do what they need, e.g., hooks where we need some.