[cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Craig Scott]

On Wed, Jan 4, 2017 at 11:43 AM, Stephen Kelly <steveire at gmail.com> wrote:

> René J.V. Bertin wrote:
>
> > The
> > issue was a project that requested an earlier CMake version
> > (2.8.something) further down.
>
> There should be no 'further down'. There should be exactly one use of
> cmake_minimum_required per buildsystem. If you are hitting this issue
> because you are cloning random repos and using add_subdirectory, you're
> essentially getting undefined behavior, unless the target repo is designed
> to let you do that.
>
> That is - some buildsystems check whether they are top-level and only then
> invoke cmake_minimum_required. Something like:
>
>  if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
>    # Building standalone
>    cmake_minimum_required(VERSION 3.3)
>    project(Dependency)
>  endif()
>
>  add_executable(etc)
>
>
>
> if you use add_subdirectory with top-level projects which don't explicitly
> do something like that, you're getting undefined , and generally unexpected
> behavior in many ways.
>

This seems at odds with the CMake documentation for
cmake_minimum_required(). That documentation talks about calling
cmake_minimum_required() within a function as a valid case, which is
obviously not going to be at the start of a top level CMakeLists.txt file.
I see no reason why having multiple calls to cmake_minimum_required()
shouldn't work. Yes, each one will alter the policy behaviour for that
scope and below, but assuming that's what the project wanted to enforce,
this should be fine.

We have many projects which do exactly the scenario you mention above where
a project can be built standalone or added to another project via
add_subdirectory(). We have not found it necessary to test if a project is
top level or not before calling cmake_minimum_required(). The behaviour is
well-defined and performs as per the documentation in regard to policies
and minimum CMake versions as far as we've observed. Can you point me/us at
documentation or code which shows why this should be considered undefined
behaviour? I'm particularly interested in this case since we use it
frequently in production.

Also, in case it is of interest, in a hierarchical project arrangement
where another project is brought in via add_subdirectory, the
CMAKE_POLICY_DEFAULT_CMPNNNN
<https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_DEFAULT_CMPNNNN.html>
variable
can be used to alter the default for a policy so that if that sub-project
specifies an older version in its cmake_minimum_required(), the
driving/main project can still influence its behaviour without requiring
changes to that sub-project. Not ideal, but I've had at least one
legitimate case where this was useful (dealing with warnings associated
with CMP0048 <https://cmake.org/cmake/help/latest/policy/CMP0048.html>).


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170104/46a9618e/attachment.html>