> On Feb. 3, 2014, 8: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.

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.


- Raphael


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115395/#review48846
-----------------------------------------------------------


On Jan. 30, 2014, 1:18 a.m., Alexander Richardson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115395/
> -----------------------------------------------------------
> 
> (Updated Jan. 30, 2014, 1:18 a.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

Reply via email to