> On Feb. 3, 2014, 6:07 p.m., Raphael Kubo da Costa wrote: > > Please see the big comment below the elseif line, the link to the > > kde-core-devel and > > http://lists.kde.org/?l=kde-core-devel&m=138244424421211&w=2: the issue > > here is that if you pass -fno-exceptions to clang you need to guarantee it > > is not going to include any headers that throw exceptions either, even if > > it is in some template code that never gets instantiated. > > > > For example, this does not build with clang++ -fno-exceptions, but does > > with GCC 4.8: > > > > #include <exception> > > template <typename T> > > struct S { void f() { throw std::exception(); } }; > > > > This was a problem for kdelibs including OpenEXR headers, or kdepim > > including pimlibs headers that all fell into this case. > > > > Alex Merry wrote: > Arguably, the solution here is to always enable exceptions for code that > encounters this (as we do for the OpenEXR QImage format plugin, for example). > > Alexander Richardson wrote: > It works with all the STL headers, the question is should we have > everything built with clang be 7% bigger, or just enable exceptions in those > cases where it breaks compilation? I don't really mind either way, I just > realized that all of frameworks builds fine even with -fno-exceptions. > > Raphael Kubo da Costa wrote: > The situation might be easier with frameworks and we can choose to > selectively enable exceptions where necessary; I only worry about ending up > having to play catch up with libraries that suddenly end up including headers > that throw exceptions via a dependency of a dependency, or issues going > undetected due to everyone using GCC. > > Alex Merry wrote: > The choice, I guess, is between making life easy for Clang users by > avoiding errors that don't crop up with GCC, and making use of Clang's better > diagnostics to catch these sorts of problems. I'm not sure which we should > be going for. > > Kevin Ottens wrote: > I'd lean toward making use of clang's better diagnostics to be honest. > Means we need a clang build of frameworks too on the CI though. > > Alexander Richardson wrote: > Ok good, I will update this review to address the raised issues.
Any news? - Kevin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115395/#review48846 ----------------------------------------------------------- On Jan. 29, 2014, 11:18 p.m., Alexander Richardson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115395/ > ----------------------------------------------------------- > > (Updated Jan. 29, 2014, 11:18 p.m.) > > > Review request for Build System, Extra Cmake Modules and KDE Frameworks. > > > Repository: extra-cmake-modules > > > Description > ------- > > Also pass -fno-exceptions when building with clang > > All of KF5 + kate + kde-workspace compile with clang and -fno-exceptions > > The only problem related to clang and -fno-exceptions I could find was > http://llvm.org/bugs/show_bug.cgi?id=10910 and that is fixed since > clang version 3.0 which was released in December 2011 > > > Diffs > ----- > > kde-modules/KDECompilerSettings.cmake > 335e1270d19f8342e41b22e7081dea3f7ac0fbfc > > Diff: https://git.reviewboard.kde.org/r/115395/diff/ > > > Testing > ------- > > compiled all of kf5 + kate + kde-workspace without any issues using clang 3.3 > > Would be good if someone with an older clang version could test it and see > whether it works. > May also be related to the libstdc++ headers (4.8 installed here). > > > Thanks, > > Alexander Richardson > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
