Hi Akim, For my part, when this all happens is unimportant. Nowadays, I'm writing stuff that should build and run anywhere, let alone requiring recent GNU tools. So if you have delays, it won't bother me at all.
On 06/15/12 07:22, Akim Demaille wrote:
Sorry I failed to send the introduction message (and actually lost it). There are two shortcomings. (i) When using yacc.c, parser.c now includes parser.h instead of duplicating its content. glr.c and lalr1.cc already work like this. Yet it means that parser.c must know where parser.h is in order to #include it. Currently all the implementation files (with yacc.c, glr.c, lalr1.cc, glr.cc) include the basename of header file, so -I should suffice to find it. But instead of basename, I am contemplating the use of code from coreutils to compute relative paths, to handle cases such as --output=a/b/c/my-parser.c --defines=a/d/my-header.h (but, as I reported elsewhere, I am stunned by the impact this gnulib modules would have, comments most welcome: http://lists.gnu.org/archive/html/bison-patches/2012-06/msg00023.html).
Too complicated. The output parser should #include the header using just the base name surrounded by double quotes. If the header gets redirected to another directory, it becomes the responsibility of the developer to specify the correct -I option. All that relative directory path stuff is very cute, but of little practical value and adds too many inter-dependencies for what I see as a marginal gain. One very useful addition will be adapting ylwrap. As it stands now, the .h file is always thrown away. Ick. Consequently, I have to auto-edit the ylwrap script to preserve the header, and that is quite a nuisance. I'm sure that that is a autoconf/automake issue tho.
(ii) YYSTYPE and YYLTYPE are not renamed. As already discussed, this will be covered by some new %define api.prefix "foo" which will deprecate %name-prefix.
That will be very nice. Thanks! Cheers - Bruce
