rjvbb added a comment.
Usually if you have a conditional behaviour the associated condition specifies when to trigger it, no? You're right that the names don't suggest exactly how the condition is being evaluated (with extra checks or not), but that was also a bit the idea. Don't bother the user with such details, just provide a macro that will add the flag(s) if they are supported, with an optional conditional expression that can make things faster. Not that this optimisation makes a huge difference in my experience, so the already suggested simplification of just querying the compiler for everything isn't completely off the table either AFAIAC. > In summary, I suggest having both SUPPORTED_IF and TRY_IF, and moving AppleClang magic out of the function. So: SUPPORTED_IF : add the flag(s) if the expression is true? TRY_IF: query the compiler if the expression is true? How would that intersect with the SUPPORTED_IF test? What about the macro name itself in that case? What bothers me here is that it puts the responsability to invoke magic or not back in the hands of the users, most of whom cannot test (directly) on the platform where this is needed. That could well open the door to new issues, either when a new problematic flag is added, or if someone thinks that some cleanup is in order and safe. Counter proposal: add a SUPPORTED_BY or SUPPORTING_COMPILERS parameter that take a list of compiler IDs for flags like -pedantic that are supported by all versions and can thus be added with only a simple compiler check. The question then is if an error should be raised if both parameters are specified? 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
