Sam Steingold <sds <at> gnu.org> writes: > >> (drop m4_popdef, replace m4_pushdef with m4_define) > > > > m4_pushdef/m4_popdef is nicer than m4_define, in that your use of the macro > > name becomes a local variable (you aren't corrupting state if anything else in > > the configure.ac happened to use the same name for an unrelated macro). But > > m4_define works all right if you have no reason to suspect that the macro name > > will ever collide. > > interesting. > > I thought that I was modifying a local variable. In the case of m4_foreach_w([cl_feat]), yes, you happen to be modifying a local variable after all, since m4_foreach_w is doing a m4_pushdef/m4_popdef of cl_feat under the hood. But it's nicer to get into good habits, rather than relying on internal implementations. > m4_foreach_w([cl_feat], [$1], > [ m4_define([cl_feat], ...) ]) > > leaks cl_feat outside of m4_foreach_w? If we ever change how m4_foreach_w is implemented, such that cl_feat is no longer managed by an invisible m4_pushdef/m4_popdef, then yes, your raw definition of cl_feat would leak. On the other hand, by doing the m4_toupper up front, then you aren't changing how cl_feat is modified under the hood, and can guarantee no leak even if we change our implementation. > > m4_foreach_w([cl_feat], m4_toupper([$1]), > > [AC_CACHE_CHECK([for cl_feat in CLISP], .... > > even better! will use this! Glad you agree. -- Eric Blake _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
