Re: RFC: m4 2.0 --prepend-include option

[Paul Eggert]

Eric Blake <address@hidden> writes:

> http://lists.gnu.org/archive/html/m4-patches/2003-06/msg00002.html
>
> It looks like an incomplete patch (intentionally tabled until post 2.0)

That's fine, but why does it depend on POSIXLY_CORRECT?  If the change
is tabled, perhaps it should just be disabled in all cases, to avoid
confusion.

>>    3.  Whether 'define' implies 'undefine' or 'popdef'.
>> ...
>> For (3) perhaps we can ask POSIX to allow the GNU behavior; then
>> we can remove the POSIXLY_CORRECT dependency.
>
> Actually, for (3), I'm not even sure POSIX has an opinion one way or the
> other - it is only the NEWS file of GNU m4 that claims that POSIX required
> the undefine() behavior,

I just now read the POSIX spec and I agree with you: it does not
clearly state the behavior one way or the other.  Therefore GNU m4 can
and should do it the "right" way, regardless of POSIXLY_CORRECT.  Or,
if you want to be more conservative about this, we can ask for a
ruling that this is OK (I'm pretty sure the answer will be "yes" given
the longstanding default behavior of GNU M4).

> Other places where I know GNU is currently incompatible with POSIX, but
> where POSIXLY_CORRECT does not (yet) have an effect:
>  (6) GNU accepts character ranges in `translit', although I intend to file
> an aardvark to allow this extension

Sounds good.

>  (7) GNU treats many builtins as blind (ie. `eval' without arguments
> expands to `eval', not `0'), but I don't know if an aardvark is worth it,
> as it affects quite a few of the builtins

Well, I suppose I could put it on my list of things to do.  :-)
Admittedly it's low priority.

>  (10) whether file inclusion searches a path; seems like a clean extension
> of POSIX to me, and should not be conditional

Yes.  It is a pure extension if the user specifies a -B option or
suchlike.

>  (11) whether macro tracing survives the macro being undefined; seems like
> a clean extension to me, and should not be conditional

Yes.  It seems to me POSIX does not specify the behavior here so we
can do what we like.

>  (12) whether the 'traditional' or 'gnu' module is loaded at startup

What is the significance of this?  If it's merely a matter of which
macros are builtin, I think POSIX allows M4 to predefine whatever
extra macros it likes (though obviously this shouldn't be overdone).
Solaris 10 m4, for example, predefines the macro 'unix'.  So if it's
just a macro visibility issue, POSIXLY_CORRECT shouldn't matter here.

>  (13) whether `m4wrap' takes multiple arguments

Perhaps an Aardvark should be filed for this as well?

> a POSIX nerd could theoretically implement a
> POSIX m4 by a simple wrapper script and a (not yet written) posix module:
> #!/bin/sh
> export POSIXLY_CORRECT=1
> exec /path/to/gnu/m4 -m posix "$@"

By "POSIX m4" you mean an M4 that supports only POSIX features, and
nothing else?  I don't think this is worth our worrying about.

But if you mean an M4 that conforms to POSIX, then it shouldn't be
that complicated; setting POSIXLY_CORRECT alone should suffice to
conform to POSIX.  But it'd be fine if POSIXLY_CORRECT implied -m
posix, where we supply the posix module.

> autom4te already uses -B as a synonym for --prepend-include, modeling it
> after gcc's -B.

Ah, OK.  In that case, I suggest changing GNU m4 -B to be consistent
with the other GNU programs.  Even if someone uses the SunOS syntax
(which I think is rare), it'll still work, unless they have a
directory whose name consists entirely of digits, which is quite
unlikely.  The only package I know of that uses SunOS "m4 -B" is
OpenSSL (it uses "m4 -B 8192), and its use is safe in this respect.
I expect others are similar.

> nuking -S and -T support (the other two arbitrary limit tweaking parameters of
> Solaris m4) rather than leaving them in as undocumented no-ops.

OK.  A more-conservative approach would be to put in warnings that
they're going to be removed in a future version.  I don't know of
anything using either -S or -T, but there's no rush deleting them.