> On 7 Jul 2018, at 12:14, David Kastrup <d...@gnu.org> wrote: > > Hans Åberg <haber...@telia.com> writes: > >> The first step would probably to switch to a later compiler with a >> flag for an older C++ version. Then one can test later C++ versions in >> independent builds. > > We are not really sticking with older language versions as an > intellectual exercise but in order to stay with a least common > denominator of actually employed compilers. Going to the bleeding edge, > even with compatibility flags, when the main distributions and/or our > users/integrators aren't there yet is not quite representative. > > "I cannot reproduce your problem" is something I want to avoid. I think > we are at a stage where C++11 is ok to demand, C++14 does not bring a > whole lot to the table, and C++17 is too early yet.
There is a danger in using an older compiler that is not supported, as there might be bugs that are not going to be fixed. > We had some fallout when I used C++08 overload resolution rules for > dealing with inherited acknowledgers I thought just try to compile without introducing any new features with later compilers and later C++ version flags. The stuff that does not work with C++17 could be removed, then use an earlier version flag for the distribution to ensure newer language features are not there. > and it turned out Clang++ was buggy > in that regard. It took long time to get C++11 right, so it is best to avoid older compilers I think. > In that case, I decided not to dial back the > refactoring because it would have been a lot of work and the result > would have been considerably more ugly, but if we had caught that early > on, the decision might have been different. Also Clang++ is kind of low > priority since none of our official binaries are compiled in that manner > and it's not clear there is a two-digit number of users/integrators > working with a Clang++/LilyPond setup. I got tired at the outdated clang that comes with MacOS, so I downloaded clang6 at their site and copied into /usr/local/clang so it is easy to remove. Then setting Automake to use it in a separate build worked fine, also with the Xcode debugger. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
