Hans Åberg wrote: > >> Before it gets integrated into the Bison distribution, you might > >> want to put it in the package source directory. > > > > I won't for my code (but you, or anyone else, may want to). FWIW, I > > need patches to some Debian packages, some of them for years as many > > maintainers don't seem very interested in bug fixes (that don't > > affect them personally), unfortunately. So I keep a directory of all > > such patches, so I can easily reapply them after upgrades, and my > > Bison patch will just join them there, until it's integrated, or > > otherwise forever (probably not the only one): ... > > I meant in the source directory of your program.
I understood that. I won't put it in my source directory, just like I won't put patches to JACK, FTGL and other long-time-no-maintenance packages there. I put those patches separately, install them once when I set up a new system, and keep my source code clean. > >> I was able to do it, with the following changes: > >> > >> In the .yy file, I had to put in "./", to: > >> %skeleton "./lalr1-c++17.cc" > >> There seems to be a bug in Bison 3.0.4, looking only in the installation > >> directory if it is not there. > > > > Bug or feature, I don't know. Maybe it's supposed to work this way. > > Check %skeleton in Bison Declaration Summary, 3.7.12. So the behaviour seems correct, to find it in the current directory you do need "./": : If file does not contain a /, file is the name of a skeleton file in : the Bison installation directory. If it does, file is an absolute : file name or a file name relative to the directory of the grammar : file. This is similar to how most shells resolve commands. > > I will now submit my changes to savannah. If the maintainers react > > to them, great, and we can discuss the details; otherwise, I think > > doing anything else now would just be a waste of time. > > If you get it accepted, there may not be need for special file > names: It would suffice to set '#if (__cplusplus >= 201103L)' > around the C++11 code. Not sure. My code changes user-visible behaviour (e.g. building of tokens, see my reply to Piotr), and changes the available %directives, so it doesn't seem suitable to make all that dependent on the compiler settings. Also, the skeletons would get (even more) unreadable, containing near-duplicated versions of a lot of code. I think in this regard, it's better to consider C++03 and C++17 two different languages, like C vs. C++. In the long run, maybe the C++03 skeleton can be faded out, but that's not my decision to make. Regards, Frank