On 2014-01-27 16:58, 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. These VERSION variables are not alone in 'conflict
possibilities' in that case. The 'sub-project' already may not use
CMAKE_SOURCE_DIR
Huh? Of course it can; it just needs to know that CMAKE_SOURCE_DIR !=
the sub-project's source dir. (In fact, testing this is probably the
canonical way to determine if a project is embedded or not.)
The reason for handling project(VERSION) specially was so that the
parent project can start using project(VERSION) but arrange that the
behavior of project() won't suddenly change within the subproject, in
case the subproject is already using variables with the same names as
the version variables that project() would otherwise newly unset.
and there are other constraints which we don't have
listed/documented anywhere. There are existing reasons why ExternalProject
should be used instead of add_subdirectory in such cases. These VERSION
variables can just be another reason. The 'host' buildsystem would itself
have to set the VERSION, so it can ensure that that actually works with its
sub-directory projects.
There should not be special behavior with these VERSION variables. Or if
there really should be, the reason should be in the commit message.
I haven't looked at the actual commits; it may be their messages could
be improved. I don't think it's so hard to avoid gratuitous breakage of
nested projects however that it isn't worth doing so.
And in fact, I believe it isn't just nested projects that would break,
but any project that was using the same variable names as
project(VERSION) would set... We really don't want the behavior change
that, without any modification to CMakeLists.txt, project() suddenly
unsets variables. (I suppose there is a policy argument that could be
made there, but using CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND
instead gives us reasonable behavior implicitly, and allows for projects
nesting other projects to avoid breaking the nested projects.)
That said, I'm assuming the behavior is as described in
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9108
and preceding, and NOT as described in
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9113
which is overkill.
--
Matthew
--
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
