Le 15 juin 2012 à 18:20, Bruce Korb a écrit : > Hi Akim,
Hi Bruce, > 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. Actually, IIRC, the bug report that led to the use of basename would have been handled properly with relative. Personally, I am unhappy that basename is used. In several projects I work on, headers form a hierarchy, so I really want my --defines=parse/parser.hh to end in a header installed in parse/, and #included this way. Yet I agree that this cannot suffice for everybody. So we should probably split this in two: --defines provides the place where the file will be created, and some other mechanism should provide the name under which it is #included. So I could happily have --defines=$(top_srcdir)/include/vcsn/parse/parser.hh for instance, and have #include "vcsn/parse/parser.hh" in the implementation file. Some people have expressed the desire to be able to use a single location.hh header instead of several. A means to specify the names of the files to include could also help here (though I have to think more about it). Then the question remains on what the default should be: basename or relative. > 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. Recent versions of Automake have addressed a number of issues on this regards, so you should give them a try, and make a bug report if you still have a problem. I never had the problem you describe. >> (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! I started to work on this. It's in the api.prefix branch on the master repository. IMHO, this should be named 2.6, not 2.5.1.
