[CMake] General modernization facility
On Dec 18, 2007 9:36 AM, James Bigler [EMAIL PROTECTED] wrote: I also agree that trying to maintain backwards compatibility to the detriment of the future can become a hinderance. I just had a collegue who was extreemly frustrated for several hours with why his build didn't work, only to discover that he should have been using ADD_SUBDIRECTORIES instead of SUBDIRS. There was no warning from CMake stating that he shouldn't be using it (I would argue that CMake should warn about the use of SUBDIRS). General warning facilities, and a standard way of turning on future looking options, so that people do not have to be stuck in the past if they don't want to be, would be good. CMake CVS has the set_properties(GLOBAL PROPERTIES var1 value1 var2 value2 ...) mechanism. So if we didn't bother with the bool(var [value]) interface I proposed, we could selectively apply Alex's patch using set_properties(GLOBAL PROPERTIES ORDINARY_Y_N_STRINGS TRUE). Or maybe someone can think of a better name for it. Collections of options such as this could be put in a standard module called Modern. include(Modern) would turn on improvements that are clearly desirable but break backwards compatibility. Flagging SUBDIRS as an error would be the kind of thing you'd stick into Modern. If a user does include(Modern), they're saying they want whatever is currently considered the best practice, even if that breaks something. It should be clearly documented as having that purpose. Heh, I wonder if in some instances the opposite would be needed, include(Ancient) ! :-) Something that either suppresses appeals to modernity, or warns vehemently against them. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] General modernization facility
Brandon Van Every wrote: On Dec 18, 2007 9:36 AM, James Bigler [EMAIL PROTECTED] wrote: I also agree that trying to maintain backwards compatibility to the detriment of the future can become a hinderance. I just had a collegue who was extreemly frustrated for several hours with why his build didn't work, only to discover that he should have been using ADD_SUBDIRECTORIES instead of SUBDIRS. There was no warning from CMake stating that he shouldn't be using it (I would argue that CMake should warn about the use of SUBDIRS). General warning facilities, and a standard way of turning on future looking options, so that people do not have to be stuck in the past if they don't want to be, would be good. CMake CVS has the set_properties(GLOBAL PROPERTIES var1 value1 var2 value2 ...) mechanism. So if we didn't bother with the bool(var [value]) interface I proposed, we could selectively apply Alex's patch using set_properties(GLOBAL PROPERTIES ORDINARY_Y_N_STRINGS TRUE). Or maybe someone can think of a better name for it. Collections of options such as this could be put in a standard module called Modern. include(Modern) would turn on improvements that are clearly desirable but break backwards compatibility. Flagging SUBDIRS as an error would be the kind of thing you'd stick into Modern. If a user does include(Modern), they're saying they want whatever is currently considered the best practice, even if that breaks something. It should be clearly documented as having that purpose. Heh, I wonder if in some instances the opposite would be needed, include(Ancient) ! :-) Something that either suppresses appeals to modernity, or warns vehemently against them. Perhaps this could be enforced by CMAKE_BACKWARDS_COMPATIBILITY variable. If you supply a sufficiently modern version of cmake, then deprecated things will turn on warnings/errors. If you set the version lower, then features that were not deprecated at that version wouldn't issue warnings. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] General modernization facility
On Dec 18, 2007 1:06 PM, James Bigler [EMAIL PROTECTED] wrote: Brandon Van Every wrote: include(Modern) would turn on improvements that are clearly desirable but break backwards compatibility. Heh, I wonder if in some instances the opposite would be needed, include(Ancient) ! :-) Something that either suppresses appeals to modernity, or warns vehemently against them. Perhaps this could be enforced by CMAKE_BACKWARDS_COMPATIBILITY variable. If you supply a sufficiently modern version of cmake, then deprecated things will turn on warnings/errors. If you set the version lower, then features that were not deprecated at that version wouldn't issue warnings. How about include(ForwardsCompatibility). That would make the intent really clear. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
