> Bruce> Ah, the light dimly dawns. We need M4 to support > Bruce> pushquote/popquote. > > >> changecom, changequote, changeword and changesyntax are only > >> command line options which are moved into the M4 language....
> Paul> Aren't you two in violent agreement? I think Bruce now > Paul> understands why changequote doesn't work, and he is thinking of > Paul> a new GNU M4 feature that should do what he wants. > But of course, if you can *prove* when you pushlanguage that you never > invoke the other language before the poplanguage, it is sane. But > then it means: you use no other Autoconf macro, and you don't use > users' arguments (given they, too, belong to the [ ] world). I think we all know how to program and we are, perhaps, picking at nits just because our English is not as rigorous as our programming. I'm pretty sure I've been guilty of that during this exchange. (I do think the horse has likely died by now...) But, just to be really sure of its death ;) ... Adding push/pop quote to M4, to be useful in this context, would also require that any macros that depended upon a particular quoting phrases being current would need to push/pop it to what it needed. It would take some work. Meanwhile, back to the "What to do?" issue that started this, I have reached the conclusion that no solution works. Akim favors burdening (my term) the user with worrying over the balancing of square brackets. I am in favor of an interface whereby the user types in the script and program exactly the way they want the text to be seen by /bin/sh and cc, respectively. I believe that it is the responsibility of either autoconf or a layer over autoconf to do whatever is required to push that text through all the autoconf layers so that the final configure script is doing exactly what was originally typed. How that is done is proving to be an "interesting" exercise. The reason I now think no solution works is because of quoting. Changequote works, but only if assured that it will not surround any AC_* macros. Global replacement of square brackets with quadrigraphs has, it turns out, the same issue. It's also ugly. Scanning the source to ensure balance and replacing unbalanced square brackets with quadrigraphs also has this Achilles heel, but is less likely to be hit. Additionally, it is pain to write and I really do not see general application for it. It seems the only reasonable solution I can see is to provide several ways to massage the text, one of which being to require the user to fix the quoting issues. At least I can put a big, bold caveat next to the input text that links to a help page discussing the various issues and ways around them. Akim went on to say: > If [there's anything] I'm proud of, it is [...] of having understood > proper M4 programming. I found no documentation at all about it, no > doubt people were writing bad M4. I consider I saved Autoconf thanks > to that. > > But some think I killed it. Despite the fact that I detest M4 quoting, let me make it clear that I do, in fact, appreciate the rigor you have brought to autoconf. In fact, this rigor makes it possible to do an automated or near-automated conversion of autoconf from an M4 based to an AutoGen based set of macros. :-) Doing so would completely eliminate this discussion. AutoGen macro markers cannot be confused with source text, ever. But not today. > My point is, novices don't write macros, My point is, novices don't write macros. They don't because the learning curve is much steeper than it needs to be. > and slightly more advanced > users don't have problems at all for writing macros by hand. "at all" is too strong. Witness the recent issue regarding argument quoting with Glenn McGrath, someone who is clearly familiar with autoconf. > You will have to explain what is so hard about writing things like > > # AC_FUNC_ERROR_AT_LINE > # --------------------- > AC_DEFUN([AC_FUNC_ERROR_AT_LINE], > [AC_LIBSOURCES([error.h, error.c])dnl > AC_CACHE_CHECK([for error_at_line], ac_cv_lib_error_at_line, > [AC_LINK_IFELSE([AC_LANG_PROGRAM([],[error_at_line (0, 0, "", 0, "");])], > [ac_cv_lib_error_at_line=yes], > [ac_cv_lib_error_at_line=no])]) > if test $ac_cv_lib_error_at_line = no; then > AC_LIBOBJ(error) > fi > ]) That is very hard for the novice. They just want to know, "Is error_at_line() available?" Understanding the above is very hard compared with: > group = "ag"; > test = { > name = "error_at_line"; > type = "link"; > check = "error_at_line is available"; > code = <<- _END_OF_CODE_ > #include <error.h> > main() {error_at_line (0, 0, "", 0, "");} > _END_OF_CODE_; > > action = { no; > act-type = script; > act-text = <<- _END_OF_SCRIPT_ > AC_LIBOBJ(error) > _END_OF_SCRIPT_; }; > }; (which I created by filling in the web page). This is the result: > AC_DEFUN([AG_LINK_ERROR_AT_LINE],[ > AC_MSG_CHECKING([whether error_at_line is available]) > AC_CACHE_VAL([ag_cv_link_error_at_line],[ > AC_TRY_LINK([@%:@include <error.h> > main() {error_at_line (0, 0, "", 0, "");}], > [ag_cv_link_error_at_line=yes],[ag_cv_link_error_at_line=no] > ) # end of TRY_LINK]) # end of CACHE_VAL > AC_MSG_RESULT([${ag_cv_link_error_at_line}]) > > if test "X${ag_cv_link_error_at_line}" = Xno > then > AC_LIBOBJ(error) > fi > ]) # end of AC_DEFUN of AG_LINK_ERROR_AT_LINE I think the autogen input lowers the bar considerably, despite the ugliness of the ``#include'' directive. -- Bruce Korb <first initial + last name at gnu dot org> AG URL: http://autogen.sourceforge.net