FindKDE4Internal.cmake & clang & c++11 & -fdelayed-template-parsing

[Raphael Kubo da Costa]

Milian Wolff <mail at milianw.de> writes:

> Hey Raphael!
>
> Thank you for working on clang support in FindKDE4Internal.cmake.
>
> Since recently though I have build issues with clang due to the -fdelayed-
> template-parsing flag passed in FindKDE4Internal.cmake. A simple example such
> as this:
>
> #include <vector>
> int main() { std::vector<int> v; return 0; }
>
> produces with: clang++ -std=c++11 -fdelayed-template-parsing test.cpp
[...]
> Apparently, delayed template parsing is not yet mature. So - can we disable it
> in FindKDE4Internal.cmake again? Or do you know a workaround for that?

Hi,

Sorry for not answering earlier.

As explained in the comment in FindKDE4Internal.cmake, simply not
passing -fdelayed-template-parsing causes a lot of problems due to us
building most repositories with -fno-exceptions and including template
code that does not get instantiated and throws exceptions: for example,
kdepimlibs' akonadi/itempayloadinternals_p.h throws some exceptions in
code that should not be reached, and while that code is built with
exceptions enabled, kdepim may end up indirectly including that header
without ever knowing it needs to enable exceptions in the first place
(which is what happened when I was testing clang support). The same
thing happened with kdelibs and OpenEXR too.

Contrary to GCC, MSVC and ICC, clang complains and fails to build if
that happens (and is probably doing the right thing).

One option is to fix all places where this might arise (it's manual and
error-prone work), or just remove -fno-exceptions from the default
compiler flags for clang in FindKDE4Internal.cmake. I tend ot favor the
latter, but it will increase the size of the generated binaries (thiago
estimated them to increase by ~5-7%).