dfaure added a comment.
Ah. You meant an "OR", I thought it was an "AND". (as in `our known selection of compilers OR/AND appleclang supports it`) But things are certainly not clearer now with the name CONDITION, which doesn't imply either one. Aside from the AppleClang issue, I've had cases where a compiler flag was added in an unreleased version of the compiler, so it makes sense to me to have a way to have a TRY_IF condition. At the same time, I guess we can have SUPPORTED_IF for the cases where we know it's supported and we want to save time by not even checking it. Then one could say "TRY_IF apple and clang" for the flags that we want to double-check on appleclang, instead of the function having this black magic hardcoded inside. And this way we don't need to check flags that work on all versions of clang like -pedantic. In summary, I suggest having both SUPPORTED_IF and TRY_IF, and moving AppleClang magic out of the function. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D16894 To: rjvbb, #build_system, kfunk Cc: dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, #build_system, michaelh, ngraham, bruns
