[cmake-developers] Preparing for CMake 3.0.0-rc1
mw_triad at users.sourceforge.net
Mon Jan 27 17:59:31 EST 2014
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
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
and preceding, and NOT as described in
which is overkill.
More information about the cmake-developers