<table><tr><td style="">dfaure added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D16894">View Revision</a></tr></table><br /><div><div><p>Ah. You meant an "OR", I thought it was an "AND".   (as in <tt style="background: #ebebeb; font-size: 13px;">our known selection of compilers OR/AND appleclang supports it</tt>)<br />
But things are certainly not clearer now with the name CONDITION, which doesn't imply either one.</p>

<p>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.<br />
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.<br />
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.<br />
And this way we don't need to check flags that work on all versions of clang like -pedantic.</p>

<p>In summary, I suggest having both SUPPORTED_IF and TRY_IF, and moving AppleClang magic out of the function.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R240 Extra CMake Modules</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D16894">https://phabricator.kde.org/D16894</a></div></div><br /><div><strong>To: </strong>rjvbb, Build System, kfunk<br /><strong>Cc: </strong>dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, Build System, michaelh, ngraham, bruns<br /></div>