Hans Åberg wrote: > > 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.
One can always have a local installation. I prefer modularization; I don't want to clutter my packages with foreign patches. It would also make maintenance more difficult in the future; e.g. I've just found an unrelated problem (https://savannah.gnu.org/patch/?9620) that affects both the old and new skeletons. I applied it in my Bison data file; otherwise I'd have to apply it in each of my packages (and if some of them used the old skeleton, make a full copy of them, and patch them). Anyway, this is only my choice. As I said, anyone can do it as they like. > > 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? Yes, the skeleton uses move semantics (i.e. rvalue references), so C++11 is the minimum. (Not entirely sure if I accidentally used some C++14 feature, as that's what I tested with besides C++17, but if so, it may be rather easy to avoid.) > > 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. I have no idea how much they are used. I think/hope most of them should be able to switch to the new skeletons rather easily (though not entirely without changes, see above). And of course, I agree that it would be best to just have one C++ skeleton, especially if maintenance manpower is sparse. Regards, Frank