[CMake] include_extenal_msproject() dependency behavior change between 3.13.4 and 3.14.0-rc2 (possible bug in rc2)

nick at appletonaudio.com nick at appletonaudio.com
Tue Feb 26 06:05:59 EST 2019


Hi Craig,

Thanks for the info. I've verified that the revision you pointed me to 
(24b6e4830d9027e63db7dfafa500aaeb652d3a4c) is where the behavior broke 
(I built CMake using the revision directly before this one and 
everything still works fine). I'm no expert with CMake development - 
could someone chime in on whether what I am seeing is expected or 
whether something has inadvertently been broken?

Testing this is actually quite simple. There is no need to even have 
valid external vcproj files on the file system - CMake does not appear 
to care if they exist or not when generating the solution. The most 
trivial test I can give to reproduce the behavior is:

./CMakeLists.txt:
cmake_minimum_required(VERSION 3.4)
project(frontend_test)
add_subdirectory(deps "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" 
EXCLUDE_FROM_ALL)
add_executable(frontend1 main.c)
target_link_libraries(frontend1 foo1_cmake)

./main.c:
/* nothing - unimportant for the test */

./deps/CMakeLists.txt:
cmake_minimum_required(VERSION 3.4)
add_library(foo1_cmake STATIC IMPORTED GLOBAL)
include_external_msproject(foo1_cmake_extern "foo1.vcproj")
add_dependencies(foo1_cmake foo1_cmake_extern)
set_property(TARGET foo1_cmake PROPERTY IMPORTED_LOCATION_DEBUG 
"foo1.lib")
add_library(foo2_cmake STATIC IMPORTED GLOBAL)
include_external_msproject(foo2_cmake_extern "foo2.vcproj")
add_dependencies(foo2_cmake foo2_cmake_extern)
set_property(TARGET foo2_cmake PROPERTY IMPORTED_LOCATION_DEBUG 
"foo2.lib")

Invoking CMake before revision 24b6e4830d9027e63db7dfafa500aaeb652d3a4c 
and opening the solution will show that Visual Studio would like to open 
foo1_cmake_extern (and it will show as unavailable in the solution 
explorer on account of the file not actually existing).

Invoking CMake at or after revision 
24b6e4830d9027e63db7dfafa500aaeb652d3a4c and opening the solution will 
show that Visual Studio would like to open foo1_cmake_extern AND 
foo2_cmake_extern (and both will show as unavailable in the solution 
explorer on account of the file not actually existing).

Just as an FYI for the mailing list (I don't actually care about this): 
I needed to update on my machine CMake (I was previously running version 
3.6) to build CMake. This might be acceptable - but I figured that CMake 
should have used cmake_version_minimum to indicate the version I was 
using was not new enough. I did not investigate, but 3.6 bombed out with 
the following:

C:\cmakegit\cmake\build> cmake .. -G "Visual Studio 14 2015 Win64"
CMake Error at Tests/RunCMake/CMakeLists.txt:279 (if):
   if given arguments:

     "(" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL" 
"19.0.24215.1" "AND" "CMAKE_CXX_COMPILER_VERSION" "VERSION_LESS" "19.10" 
")" "OR" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL" 
"19.10.25017"

   Unknown arguments specified

Nick Appleton

On 2019-02-26 19:44, Craig Scott wrote:
> If you're able to build CMake from sources yourself, you may want to
> check if the changes from this merge request [2] are what has led to
> the change you're seeing. That relates to how the EXCLUDE_FROM_ALL
> target property is initialised when a target is created.
> 
> On Tue, Feb 26, 2019 at 2:20 PM <nick at appletonaudio.com> wrote:
> 
>> Hello,
>> 
>> We have a fairly large CMake project which uses
>> include_extenal_msproject() when we are producing Visual Studio
>> solutions to bring in projects produced using another build metadata
>> 
>> generator. We've noticed most of our Visual Studio builds have
>> started
>> failing after switching to CMake 3.14.0-rc2 (not sure where betweenn
>> 
>> 3.13.4 and 3.14.0-rc2 this issue was introduced).
>> 
>> An example of how the behavior differs can be realised with the
>> following example:
>> 
>> dependencies/CMakeLists.txt:
>> 
>> # several duplications of the following block exist replacing fooN
>> with
>> foo1, foo2, foo3, etc.
>> add_library(fooN_cmake STATIC IMPORTED GLOBAL)
>> if(MSVC)
>> include_external_msproject(fooN_cmake_extern "fooN.vcproj")
>> else()
>> # other external things happen here using ExternalProject_add to
>> end
>> up creating fooN_cmake_extern for non-VS/non-Windows builds.
>> endif()
>> add_dependencies(fooN_cmake fooN_cmake_extern)
>> set_property(TARGET fooN_cmake PROPERTY
>> INTERFACE_INCLUDE_DIRECTORIES
>> "path to foo include files")
>> set_property(TARGET fooN_cmake PROPERTY IMPORTED_LOCATION_DEBUG
>> "path to
>> foo static library")
>> # ... more properties possibly set
>> 
>> frontend1/CMakeLists.txt:
>> 
>> add_subdirectory(../dependencies
>> "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
>> EXCLUDE_FROM_ALL)
>> add_executable(frontend1 main.c)
>> target_link_libraries(frontend1 foo1_cmake foo2_cmake)
>> 
>> frontend2/CMakeLists.txt:
>> 
>> add_subdirectory(../dependencies
>> "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
>> EXCLUDE_FROM_ALL)
>> add_executable(frontend2 main.c)
>> target_link_libraries(frontend2 foo3_cmake foo2_cmake)
>> 
>> The old behavior: we could invoke CMake using a source directory of
>> frontend1 or frontend2 to get Visual Studio solutions. Only the
>> Visual
>> Studio projects which are imported using include_extenal_msproject()
>> 
>> that are dependencies of that particular frontend are included in
>> the
>> solution i.e. the VS solution for frontend1 will not include
>> foo3_cmake
>> as part of the build at all. I expect this due to the use of
>> EXCLUDE_FROM_ALL.
>> 
>> The new behavior: all frontends will include every single project
>> defined using include_extenal_msproject that CMake encounters. They
>> will
>> all attempt to be built regardless of if there is a dependency. I
>> would
>> only have expected this behavior if EXCLUDE_FROM_ALL was *not* set
>> when
>> using add_subdirectory().
>> 
>> Could someone help me to understand if the behavior change is
>> expected
>> or if this is just a bug?
>> 
>> Thanks!
>> 
>> Nick Appleton
>> --
>> 
>> Powered by www.kitware.com [1]
>> 
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
> 
> --
> 
> Craig Scott
> Melbourne, Australia
> https://crascit.com
> 
> Get the hand-book for every CMake user: Professional CMake: A
> Practical Guide [3]
> 
> 
> Links:
> ------
> [1] http://www.kitware.com
> [2] https://gitlab.kitware.com/cmake/cmake/merge_requests/2816
> [3] https://crascit.com/professional-cmake/


More information about the CMake mailing list