> The only warning that is enabled by default is to warn you about > misspelled -D options that you pass on the command line. (We think > they *may* be misspelled because they are not referenced in the > configure/generate steps... So it's just a warning.)
> You can suppress this by also passing "--no-warn-unused-cli" on the > CMake command line. Or by avoiding passing in the unused variables in > the first place. Or by sticking with CMake 2.8.3 that does not produce > this warning. > > Those are your 3 options for avoiding this warning. The question is HOW do you "stick with cmake 2.8.3" - or stick with cmake 2.8.4. This is the actual issue: there's no way to "stick with" a minor release of cmake when you distribute code, because you cannot enforce a minor release of cmake (a regular linux distribution will upgrade the minor version at some point, and this cannot be controlled). So at some point somewhere, building with cmake will throw new warnings, and there's no way to control this. As the "--no-warn-unused-cli" option would simply break the build with a previous minor release of CMake, this means that the script calling CMake needs to detect the version of cmake, and tweak the cmake command line accordingly. Dirty, at best. >From my perspective - that I understand is not shared - it would have been great not introducing this kind of compatibility break between CMake minor release by default. It could have been enabled with a new POLICY or with an explicit option switch. Maybe I'm looking in the wrong direction: is there a way to specify these variable definitions without the -D option switch? - such as environment variables for example? Thanks. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
