On 11/14/15 22:46, Stuart Henderson wrote:
> On 2015/11/14 21:39, Jérémie Courrèges-Anglas wrote:
>>
>> I'll commit this tomorrow unless I hear objections.
>
> I think it's the least bad option for now. The regex problem is
> solved with this...
>
> Index: patches/patch-data_c++_m4
> ===================================================================
> RCS file: patches/patch-data_c++_m4
> diff -N patches/patch-data_c++_m4
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-data_c++_m4 14 Nov 2015 21:00:09 -0000
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +--- data/c++.m4.orig Sat Nov 14 20:54:33 2015
> ++++ data/c++.m4 Sat Nov 14 20:56:33 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[ ]),
> +- [^\(.\)[
> ]*\(::\)?\([^][:]\|:[^:]\)*],
> ++ [^\(.\)[
> ]*\(::\)?\([^]:[]\|:[^:]\)*],
> + [\1])),
> +- [::\([^][:]\|:[^:]\)*], [} ])[} // ]b4_namespace_ref])])
> ++ [::\([^]:[]\|:[^:]\)*], [} ])[} // ]b4_namespace_ref])])
> +
> +
> + # b4_token_enums
>
> ... but then we run into problems with this from m4sugar
>
> m4_translit(m4_dquote(m4_format(m4_dquote(m4_for(
> ,1,255,,[[%c]]))m4_for([i],1,255,,[,i]))), [$*-], [*$])-)
>
> "null definition" ... m4_for itself is earlier in the file but I think
> that may require m4 scuba gear to dissect ;)
>
> Anyway I'm OK with this update with the changes we talked about offlist,
> but if anyone has ideas about either ways to change m4sugar to work
> better with our m4, or ways to change m4 to support it, it would
> be very nice...
>
>
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).
Did ask about fixing m4 long ago, no reply = nothing was done my me. Now
stated have a look.
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.
