On Wed, Jan 4, 2017 at 11:43 AM, Stephen Kelly <steve...@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
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
