Review Request 115395: Also pass -fno-exceptions when building with clang

[Kevin Ottens]

> 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.

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.


- 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20140221/eba28491/attachment.html>