<div dir="ltr">If you're able to build CMake from sources yourself, you may want to check if the changes from <a href="https://gitlab.kitware.com/cmake/cmake/merge_requests/2816">this merge request</a> 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.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019 at 2:20 PM <<a href="mailto:nick@appletonaudio.com">nick@appletonaudio.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
We have a fairly large CMake project which uses <br>
include_extenal_msproject() when we are producing Visual Studio <br>
solutions to bring in projects produced using another build metadata <br>
generator. We've noticed most of our Visual Studio builds have started <br>
failing after switching to CMake 3.14.0-rc2 (not sure where betweenn <br>
3.13.4 and 3.14.0-rc2 this issue was introduced).<br>
<br>
An example of how the behavior differs can be realised with the <br>
following example:<br>
<br>
dependencies/CMakeLists.txt:<br>
<br>
# several duplications of the following block exist replacing fooN with <br>
foo1, foo2, foo3, etc.<br>
add_library(fooN_cmake STATIC IMPORTED GLOBAL)<br>
if(MSVC)<br>
include_external_msproject(fooN_cmake_extern "fooN.vcproj")<br>
else()<br>
# other external things happen here using ExternalProject_add to end <br>
up creating fooN_cmake_extern for non-VS/non-Windows builds.<br>
endif()<br>
add_dependencies(fooN_cmake fooN_cmake_extern)<br>
set_property(TARGET fooN_cmake PROPERTY INTERFACE_INCLUDE_DIRECTORIES <br>
"path to foo include files")<br>
set_property(TARGET fooN_cmake PROPERTY IMPORTED_LOCATION_DEBUG "path to <br>
foo static library")<br>
# ... more properties possibly set<br>
<br>
frontend1/CMakeLists.txt:<br>
<br>
add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" <br>
EXCLUDE_FROM_ALL)<br>
add_executable(frontend1 main.c)<br>
target_link_libraries(frontend1 foo1_cmake foo2_cmake)<br>
<br>
frontend2/CMakeLists.txt:<br>
<br>
add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" <br>
EXCLUDE_FROM_ALL)<br>
add_executable(frontend2 main.c)<br>
target_link_libraries(frontend2 foo3_cmake foo2_cmake)<br>
<br>
The old behavior: we could invoke CMake using a source directory of <br>
frontend1 or frontend2 to get Visual Studio solutions. Only the Visual <br>
Studio projects which are imported using include_extenal_msproject() <br>
that are dependencies of that particular frontend are included in the <br>
solution i.e. the VS solution for frontend1 will not include foo3_cmake <br>
as part of the build at all. I expect this due to the use of <br>
EXCLUDE_FROM_ALL.<br>
<br>
The new behavior: all frontends will include every single project <br>
defined using include_extenal_msproject that CMake encounters. They will <br>
all attempt to be built regardless of if there is a dependency. I would <br>
only have expected this behavior if EXCLUDE_FROM_ALL was *not* set when <br>
using add_subdirectory().<br>
<br>
Could someone help me to understand if the behavior change is expected <br>
or if this is just a bug?<br>
<br>
Thanks!<br>
<br>
Nick Appleton<br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div><div><br></div><div>Get the hand-book for every CMake user: <a href="https://crascit.com/professional-cmake/" target="_blank">Professional CMake: A Practical Guide</a><br></div></div></div></div></div></div></div></div></div></div></div></div></div>