On 01/23/2014 04:08 PM, Alexander Neundorf wrote: > Any more comments left ?
Moving the discussion from http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9156/focus=9158 back to the thread where it belongs: On 01/27/2014 04:58 PM, Stephen Kelly wrote: > Though I still don't like the behavior in the topic with project() commands > without a specified VERSION and the > CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND variable etc. I don't see why > all the complexity is needed. > > From what I understand, the reason it was added is related to using > add_subdirectory to add a self-contained/standalone project to host > buildsystem. My main concern that the VERSION complexity solves is for changing behavior of existing projects that are *not* modified at all. We've established that a project() without VERSION needs to unset the PROJECT_VERSION variables because otherwise they would not correspond to the current PROJECT_NAME. However, an existing project could do # CMakeLists.txt project(Top) set(PROJECT_VERSION 1.0.0) add_subdirectory(Sub) # Sub/CMakeLists.txt project(Sub) message(STATUS "Top version = ${PROJECT_VERSION}") Since previous versions of CMake documented no special behavior for the PROJECT_VERSION variable this code is completely fine now, but would suddenly change in behavior if project() started to unset PROJECT_VERSION. So our options are (1) Design new behavior in a way that requires a change to the project to activate. (2) Add a policy. The policy should only trigger when the project() command is about to unset a PROJECT_VERSION variable that was set by user code and not by a previous project() command. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers