Milian Wolff 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 > int main() { std::vector 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%).