On 15.3.2015 03:20, Eric Blake wrote:
On 03/14/2015 05:01 PM, Matěj Týč wrote:
Hello again,
In my m4 project where I use autom4te and m4sugar (for those who are
curious - https://github.com/matejak/d8 ),
in order to be able to output anything, one has to call
m4_divert_push(1) (or something similar) at certain point. However,
every time I do that, I get the
warning: prefer named diversions
warning. I know that I can use m4_divert_push(KILL) in place of
m4_divert_push(0), but a trivial diversion e.g. for stdout is not
available (or documented). There is also a lack of documentation on how
to register a named diversion, using a macro instead of a number isn't
the right way how to make a named diversion.
Do you have any solution to this in mind? Telling autom4te to suppress
warnings doesn't feel right.
According to the manual, m4sugar defines KILL and GROW as named
diversions; m4sh (if you use AS_INIT instead of m4_init) also adds
BINSH, several HEADER-*, M4SH-SANITIZE, M4SH-INIT, and BODY. That is,
if you are using autom4te to generate a shell script, then you
eventually want to m4_divert_push([BODY]) (although you get it free by
using AS_INIT).
As for creating new named diversions, they are not documented in the
manual, but you can learn about them in the m4sugar source code
(basically, m4_define([_m4_divert(NAME)], NUMBER) will define
m4_divert_push(NAME) to use that diversion number).
Thank you for your reply!
I use m4sugar to create a file (a DB schema, a .dot file, ... - not a
bash script), so I don't want to involve m4sh.I simply manually call
autom4te -l m4sugar on definition files.
The GROW diversion seems to work nicely, but the documentation somehow
discourages using it in that way since it has another purpose (... is
used behind the scenes by topological sorting ...).
However, your advice works, one can register new diversions exactly in
the way you have described, I have defined a new diversion No. 1 as
STDOUT. Wouldn't make such diversion sense in m4sugar?
Anyway, I would like to add the documentation about this diversion stuff
too. Are you OK with that?
BR,
Matej
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
