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

[Craig Scott]

If you're able to build CMake from sources yourself, you may want to check
if the changes from this merge request
<https://gitlab.kitware.com/cmake/cmake/merge_requests/2816> 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
>
> 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 <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/6c197ec7/attachment.html>