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

Tue Feb 26 06:36:06 EST 2019

On Tue, Feb 26, 2019 at 10:06 PM <nick at appletonaudio.com> wrote:

> 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).
>

Thanks, I've recorded this in the bug tracker as issue 18986
<https://gitlab.kitware.com/cmake/cmake/issues/18986>

> 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
>

This looks unintentional too. Recorded as issue 18987
<https://gitlab.kitware.com/cmake/cmake/issues/18987>.

>
> 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
>
> >
> > Links:
> > ------
> > [1] http://www.kitware.com
> > [2] https://gitlab.kitware.com/cmake/cmake/merge_requests/2816
>

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/aec7e233/attachment.html>