Nigel Taylor <njtaylor0...@btinternet.com> writes:
[...]
> Haven't looked at the most recent diff for the Makefile, so might have
> changed.
>
> Not easy to switch to m4 as implied. More is required than the
> CONFIGURE_ENV change. ac_cv_prog_gnu_m4_gnu gets forced to yes/no "-g"
> setting is ignored, as M4_GNU = "" or "--gnu" in configure, so I patched
> configure, also possible as an alternative to bring back/update the
> output.c patch. Patching configure causes gnu m4 problems, when tests
> fail, as the changed configure causes some regeneration, and wants
> autoconf or more (I just move the configure patch out the way).
Ah ha, indeed. Since that makes the CONFIGURE_ENV parts irrelevant,
I'll drop them.
It might be a detail given the amount of work you mention below, but
maybe /usr/bin/m4 should lie better, and support long options --help
and --gnu?
> Did ask about fixing m4 long ago, no reply = nothing was done my me. Now
> stated have a look.
Nice to hear that, I wasn't aware. Awesome. :)
> m4 - Think I'm down to about the last problem with m4.....
>
> $ diff -u bison-3.0.4{.gm4,}/bison-3.0.4/examples/calc++/calc++-parser.cc
> --- bison-3.0.4.gm4/bison-3.0.4/examples/calc++/calc++-parser.cc Thu Nov
> 12 01:25:32 2015
> +++ bison-3.0.4/bison-3.0.4/examples/calc++/calc++-parser.cc Sat Nov 14
> 13:09:05 2015
> @@ -1010,7 +1010,7 @@
> // The symbols being reduced.
> for (int yyi = 0; yyi < yynrhs; yyi++)
> YY_SYMBOL_PRINT (" $" << yyi + 1 << " =",
> - yystack_[(yynrhs) - (yyi + 1)]);
> + yystack_[......................]);
> }
> #endif // YYDEBUG
>
>
> This gets over that last problem with the first example, which compiles.
> But hit the same sort of issue on the second example, but not so easy to
> get around, looks like I need to fix properly.
>
> $ cat patches/patch-data_lalr1_cc
> $OpenBSD$
> --- data/lalr1.cc.orig Fri Jan 23 06:52:50 2015
> +++ data/lalr1.cc Sat Nov 14 22:44:24 2015
> @@ -1159,7 +1159,7 @@ b4_error_verbose_if([state_type yystate, const symbol_
> // The symbols being reduced.
> for (int yyi = 0; yyi < yynrhs; yyi++)
> YY_SYMBOL_PRINT (" $" << yyi + 1 << " =",
> - ]b4_rhs_data(yynrhs, yyi + 1)[);
> + yystack_[(yynrhs) - (yyi + 1)]);
> }
> #endif // ]b4_api_PREFIX[DEBUG
>
>
>
> The patch you want is this, for c++.m4...., it works for both m4 and gnu
> m4 others don't.
>
> $ cat patches/patch-data_c++_m4
> $OpenBSD$
> --- data/c++.m4.orig Fri Jan 16 14:47:42 2015
> +++ data/c++.m4 Thu Nov 12 01:20:00 2015
> @@ -100,9 +100,9 @@ m4_define([b4_namespace_open],
> m4_define([b4_namespace_close],
> [b4_user_code([b4_percent_define_get_syncline([[api.namespace]])
> m4_bpatsubst(m4_dquote(m4_bpatsubst(m4_dquote(b4_namespace_ref[ ]),
> - [^\(.\)[ ]*\(::\)?\([^][:]\|:[^:]\)*],
> + [^\(.\)[ ]*\(::\)?\([ -9;-Z^-~]\|:[^:]\)*],
> [\1])),
> - [::\([^][:]\|:[^:]\)*], [} ])[} // ]b4_namespace_ref])])
> + [::\([ -9;-Z\^-~]\|:[^:]\)*], [} ])[} // ]b4_namespace_ref])])
>
>
> It's tab-9 not space-9 in the above.... Could scan the RE string, and
> convert [^[]:] into this.
>
>
> Next problem is m4 only supports a single digit macro arguments,
> I updated m4's eval.c to support multiple digits
>
> Bison tests with m4 go wrong on expanding this....
>
> m4_pushdef(_m4_f,
> $1[$4]$2[]$1[$5]$2[]$1[$6]$2[]$1[$7]$2[]$1[$8]$2[]$1[$9]$2[]$1[$10]$2[]$1[$11]$2[]_m4_popdef([_m4_f]))
>
> where the number of arguments depends on the number of tokens defined.
> Instead of $10 you get $1 followed by 0 with m4 or m4 -g.
>
>
> m4_f comes from autoconf lib/m4sugar/foreach.m4, in versions 2.63b -
> 2.64 of autoconf and later. Just a rare case that m_f is used with more
> than 9 arguments. foreach.m4 from autoconf is duplicated in a few/lot of
> ports for building. Could be possible to change bison.m4 etc to avoid
> using m_f, other ports / autoconf could break at some point if using
> m_f, some may have switched to gnu m4.
>
>
>
>
> The next issue is with comments // appear on the line above,
> data/c-like.m4, RE patten matching, looks for non-empty lines to insert
> // in front, may have been simpler to put /* */ around the multi-line
> comments
>
> patsubst( , [
> \(.\), [
> // \1])
>
> But . also matches new line as next character, can replace with
>
> patsubst( , [
> \([^
> ]\), [
> // \1])
>
> and works, gnum4.c, putsubst has REG_NEWLINE added if not mimic_gnu,
> adding REG_NEWLINE for all cases fixes, but breaks something else.
> Needed an extra check, if the patten contains newline, need to switch to
> REG_NEWLINE if gnu_mimic, also patsubst and regexp not setting flags the
> same way could give different results for the same RE. (May need a
> closer look). gnum4.c fixed for this flag adjustment moved into the
> twiddle routine used by both patsubst and regexp when mimicking gnu m4.
>
>
>
> Still have these additional changes from previous fix in 2011
>
> http://marc.info/?l=openbsd-ports&m=130023382518651&w=2
>
> $ cvs -R -q up -Pd regress/usr.bin/m4 usr.bin/m4
> M regress/usr.bin/m4/gnutranslit2.out
> M regress/usr.bin/m4/translit2.m4
> M regress/usr.bin/m4/translit2.out
> M usr.bin/m4/eval.c
> M usr.bin/m4/extern.h
> M usr.bin/m4/gnum4.c
> M usr.bin/m4/m4.1
> M usr.bin/m4/main.c
> M usr.bin/m4/mdef.h
> M usr.bin/m4/misc.c
> M usr.bin/m4/trace.c
>
> back to back range expansion eg [a-d-a] gives abcdcba.
> m4wrap nesting keeps line/file as well as wrap text in stack, otherwise
> gives last file included / EOF line number.
> better mimicking gnu m4 output with -g option / trace. m4 /gnu m4 if
> macro over multiple lines m4 outputs the line number of the end of the
> macro parameters, gnu m4 outputs the line number of the beginning.
> __line__, __file__ builtins mimic gnu m4 with -g option, the correct
> __file__ helps when tracing m4.
>
> I haven't seen the same error as your getting, or can't remember it.
> Might be something in these fixes. Or are you getting the result of
> running with -g missing. Just came to me, it's the RE you used in
> c++.m4, doesn't do quite what you think, that's another possibility, had
> some error there.
>
>
>
>
> Second test example fails, again it's only a small block of generated
> code, m4 itself is not falling over.
>
>
> Going to be a while, need to do a full release build with m4, and then
> ports bulk to test. Go ahead as is, with the Bison update.
Sure.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
