> On 14 Apr 2018, at 10:19, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > 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.
That wouldn't work in a distribution, as the user may not want or be able to change installation. >>>> 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. Yes. I was thinking about the program directory. >>> 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. But if someone uses their of variants type, would that require C++11? > 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. It would be best to just have one. But the variants may not have been used much.