Eric Blake <ebb9@xxxxxxx> writes: > So by that proposal, a user could then do 'POSIXLY_CORRECT=1 m4 > -B1024' to get the same behavior with GNU or Solaris m4, regardless > of the presence of ./1024, because path searches would be disabled > in the GNU version thanks to the implicit -G. This doesn't sound right. POSIXLY_CORRECT is supposed to do just one thing: change behavior where GNU applications are incompatible with POSIX. It is not supposed to disable extensions that are compatible with POSIX, nor is it supposed to affect compatibility with traditional behavior not specified by POSIX. Since POSIX does not specify the behavior of m4 -B, we can define m4 -B to mean whatever we like, independently of whether POSIXLY_CORRECT is set. > I would rather see POSIXLY_CORRECT imply -G, add an option -g > (--gnu) to override it (and some BSD versions already have -g to > turn on GNU compatibility), and then base all compatibility > decisions solely on whether -G is in effect. That would be fine, but the behavior of --prepend-include should not be affected by POSIX compatibility decisions. We want POSIXLY_CORRECT to affect behavior as little as possible. So if you go this direction, -G should not disable GNU extensions; it should merely act like POSIXLY_CORRECT does, and disable _incompatible_ GNU extensions. Most GNU applications do not have an option to disable all GNU extensions. Such an option has only a small benefit to the GNU project, and nobody uses these options except perhaps for some POSIX nerds. (I'm a POSIX nerd, and I don't use them, so my guess is that the size of the audience is zero. :-) I think it would be fine if you removed -G from M4; there's no particular reason to pollute the option space to worry about POSIX compatibility issues. Or if you want to keep -G, it would be fine to silently ignore it, or to change it to mean "disable incompatible extensions" (i.e., behave like POSIXLY_CORRECT) rather than "disable all extensions". But in the long run it'd be simplest to just remove it. While we're on the subject..... Looking at the code, POSIXLY_CORRECT now affects the following behaviors of CVS M4: 1. Multidigit arguments of $, e.g., $10. 2. Value arg signatures, whatever they are. 3. Whether 'define' implies 'undefine' or 'popdef'. 4. Whether 'undivert' accepts a non-numeric argument. 5. Whether options can follow operands in the command line. In XCU ERN 111 you asked for changes to POSIX so that (1) would be allowed as a compatible extension; if this is accepted, we can change M4 so that it supports (1) even if POSIXLY_CORRECT is defined. In XCU ERNs 99 and 101 you asked for similar changes for (4), and they have been accepted by the Open Group. In situations like these I think it's fine to drop the POSIXLY_CORRECT check; that is, the code can do (4) without worrying about POSIXLY_CORRECT. It's OK to anticipate the next version of POSIX in relatively-minor situations like these. I don't understand (2); it doesn't seem to be documented. Does it really need to depend on POSIXLY_CORRECT. For (3) perhaps we can ask POSIX to allow the GNU behavior; then we can remove the POSIXLY_CORRECT dependency. For (5) we can perhaps do the same as (3), but this is a bigger deal since it affects lots of programs, and perhaps I should attempt that (if you want to pursue it) since I know better where the bodies are buried. > If I make -B a synonym for --prepend-include, Why -B? Can't you use a different letter? Or why not just leave it alone? It's unlikely people will use this option when invoking M4 by hand, so the benefit of a short name for it is fairly small. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
