https://bugs.kde.org/show_bug.cgi?id=375195
--- Comment #9 from RJVB <rjvber...@gmail.com> --- A bit of both. I ran into this issue rebuilding the previous digiKam release (why is not relevant here). Applications that use boost are not a theoretical concern, they exist. The ECM are supposed to be a collection of convenience macros and modules, allowing among others to write more readable CMake files that are easier to maintain. As such I think they shouldn't oblige software to use rarely used constructs (and a bit alien to CMake's principle too, IIUC). If there is really no other solution here, the least that could be done is provide something that hides the syntax and offloads the obligation for developers to be aware of a rarely used compiler argument. Ideally that would be a *documented* mechanism with the effect that the compiler argument is never added to CXXFLAGS but it could also be a macro of the form `ECM_PROJECT_USES_NAMED_LOGICAL_OPERATORS`. I'm not very well versed in writing CMake code but I could put a simple prototype up on Phabricator and see what we can come up with. Maybe a sort of attribute system where you can declare specific, less common needs of the project before including the ECM modules that set up the build environment (= the SET_PROJECT_PROPERTIES feature CMake forgot to implement ;)). --- To be very honest, I wasn't even aware that the C/C++ standard define named logical operators. So I googled a bit and came across a number of good arguments why one might prefer them. Not compelling enough to change my own practice but I can very well understand why complex projects like boost use them - and I doubt that boost has any anti-MSVC agenda (didn't check, though :)). What I think the ECM should do is set the options required to make software compile on all supported/major platforms. Setting things up so that software fails to build everywhere because there exists a platform where certain practices cause build failure feels like caressing the proverbial cat against its fur. Esp. if it happens in a minor release, possibly even without documentation other than a commit message. No matter how big MS Windows is compared to all other platforms it's still a platform that's very different from KDE's main platform (Unix/Linux and derivatives). It would be much more in line with the other ECM features to figure out how to get all platforms to accept what they should be accepting in the first place. FWIW, should getting MSVC to accept named logical operators not be feasible, isn't this something that should be implemented as a CMake policy? -- You are receiving this mail because: You are watching all bug changes.
