>>>>> "Adam" == Adam J Richter <[EMAIL PROTECTED]> 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.
