Stepan Kasal wrote, quoting me: >> I *like* autoconf, but, if I have one harsh criticism, it is that >> perfectly good macro names are deprecated much too frequently. > > Yes, I miss AC_TRY_COMPILE and friends. Unfortunately, since the new > interface is (subtly) different, it was necessary to find another name. I agree, of course, that when the API changes it is necessary to change the name; but, as a replacement for AC_TRY_COMPILE, AC_COMPILE_IFELSE is still definitively an *autoconf* macro. > If a macro has nothing to do with Autoconf, it is just a feature > of the macro language, then it should be named m4_* > This is the case of m4_include, m4_if, m4_define and such. This is an esoteric distinction, which may seem important to you as a developer, but has little, if indeed any relevance to the user, IMHO. As developers, (and I include myself here, having contributed code to groff and to MinGW), we often take such decisions without adequate consideration of the users' perspective, whereas *really* we should attach paramount importance to how the user will perceive the issue, (and I confess that I too have been guilty of ignoring this tenet). However, I am not an autoconf developer; I am merely a user. So, indulge me please, and allow me to offer a user's perspective -- specifically, from *this* user's point of view. When I write my configure.ac, aclocal.m4, or acinclude.m4, *every* macro I use is, from my perspective, an *autoconf* macro. That some of these are called AC_*, AS_*, m4_*, or indeed anything else, is not important to me -- they are still *autoconf* macros. That these naming conventions have some deep significance for you, as a developer, is irrelevant to me, as a user -- indeed, they contribute only to generating a potential mish-mash of confusion. > And this is the case of AC_FOREACH; if you write > > AC_FOREACH([Boy], [Saul Fred Orrie], [Hi, Boy! > ]) > > you get > > Hi, Saul! > Hi, Fred! > Hi, Orrie! > > this is just a macro feature. It has nothing to do with shell > scripting nor with "configure script generation". Granted, this is true; but when you use this in an autoconf script, you implicitly place it into an autoconf context, and autoconf *does* have *everything* to do with "configure script generation", for that is autoconf's "raison d'être". > So AC_FOREACH is not a good name. I would respectfully disagree -- IMO, it's a perfectly good name for any macro, to be used in any autoconf context, which implements a `foreach' construct. > ... But, of course, that is not reason to touch it. But: > >> If the previous AC_FOREACH implementation is flawed, then by all >> means reimplement it the way this silly thing does, but keep the >> elegant name > > But what if the interface is broken? There is no way to add > > Hi, Paul, my dear! > > to the above loop--the string contains spaces. m4_foreach is much > better: > > m4_foreach([Boy], [Saul, Fred, Orrie], [Hi, Boy! > ]) > m4_foreach([Boy], [[Saul], [Fred], [Orrie], [Paul, my dear]], > [Hi, Boy! > ]) > > The first call is equivalent to the previous example. The second > one is fully quoted and shows that members can contain spaces and > commas. That's a different issue. Actually, I would again respectfully disagree that the interface is broken -- it merely suffers from some limitations. The right, and proper thing to do, IMO, is to document it, pointing out those limitations, and illustrating the alternative, using m4_foreach, for those cases where it may be more appropriate. > So I believe that in most cases it is better to use m4_foreach > instead of AC_FOREACH. Actually, in a private discussion Ralf > admitted that a comma separated list (so called "m4 list") might be > better for his application. > > So I'm more and more convinced that the "Foreach" node in Autoconf > manual should first describe m4_foreach and recommend it. Certainly, m4_foreach needs to be documented; but does AC_FOREACH need to be deprecated? You could equally well keep it, and document *both*, perhaps even noting that, of the two, m4_foreach *may* be the preferred choice, in most situations. > Then it would document m4_split and say: "If, for some reason, you > have to process a whitespace-separated list, you can use this > pattern: > m4_foreach([Var], m4_split(m4_normalize([$1]), [...Var...]) > supposing that $1 contains the list. But now you are saying "Perhaps you do need AC_FOREACH, but I've killed it, so you will have to use this more complex construct instead". Or, you implement your `m4_foreach_w', (to which you referred in a previous posting), and which is really just AC_FOREACH by a different name -- more user confusion. Ugh. > m4_normalize has to be documented, too, perhaps in another section, > say "text manipulation". The m4_bpatsubst could go there, too. > (It's not a redefined builtin, so there is no reason why it should > be in "Redefined M4 Macros".) I agree; *all* `m4_*' macros need to be documented, either in some section appropriate to their use, or collectively -- perhaps even both, with a collective summary pointing to detailed descriptions elsewhere. Please don't take this as any denigration of the effort that has gone into autoconf; it's an excellent tool, and I wouldn't be without it. The foregoing is simply my opinion, but perhaps the developers do need to occasionally take a step back, and try to understand the users' perspective of this complex beast. Keep up the good work. Regards, Keith. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
