<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019 at 10:06 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">Hi Craig,<br>
<br>
Thanks for the info. I've verified that the revision you pointed me to <br>
(24b6e4830d9027e63db7dfafa500aaeb652d3a4c) is where the behavior broke <br>
(I built CMake using the revision directly before this one and <br>
everything still works fine). I'm no expert with CMake development - <br>
could someone chime in on whether what I am seeing is expected or <br>
whether something has inadvertently been broken?<br>
<br>
Testing this is actually quite simple. There is no need to even have <br>
valid external vcproj files on the file system - CMake does not appear <br>
to care if they exist or not when generating the solution. The most <br>
trivial test I can give to reproduce the behavior is:<br>
<br>
./CMakeLists.txt:<br>
cmake_minimum_required(VERSION 3.4)<br>
project(frontend_test)<br>
add_subdirectory(deps "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" <br>
EXCLUDE_FROM_ALL)<br>
add_executable(frontend1 main.c)<br>
target_link_libraries(frontend1 foo1_cmake)<br>
<br>
./main.c:<br>
/* nothing - unimportant for the test */<br>
<br>
./deps/CMakeLists.txt:<br>
cmake_minimum_required(VERSION 3.4)<br>
add_library(foo1_cmake STATIC IMPORTED GLOBAL)<br>
include_external_msproject(foo1_cmake_extern "foo1.vcproj")<br>
add_dependencies(foo1_cmake foo1_cmake_extern)<br>
set_property(TARGET foo1_cmake PROPERTY IMPORTED_LOCATION_DEBUG <br>
"foo1.lib")<br>
add_library(foo2_cmake STATIC IMPORTED GLOBAL)<br>
include_external_msproject(foo2_cmake_extern "foo2.vcproj")<br>
add_dependencies(foo2_cmake foo2_cmake_extern)<br>
set_property(TARGET foo2_cmake PROPERTY IMPORTED_LOCATION_DEBUG <br>
"foo2.lib")<br>
<br>
Invoking CMake before revision 24b6e4830d9027e63db7dfafa500aaeb652d3a4c <br>
and opening the solution will show that Visual Studio would like to open <br>
foo1_cmake_extern (and it will show as unavailable in the solution <br>
explorer on account of the file not actually existing).<br>
<br>
Invoking CMake at or after revision <br>
24b6e4830d9027e63db7dfafa500aaeb652d3a4c and opening the solution will <br>
show that Visual Studio would like to open foo1_cmake_extern AND <br>
foo2_cmake_extern (and both will show as unavailable in the solution <br>
explorer on account of the file not actually existing).<br></blockquote><div><br></div><div>Thanks, I've recorded this in the bug tracker as <a href="https://gitlab.kitware.com/cmake/cmake/issues/18986">issue 18986</a></div><div><br></div><div><br></div><div> </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">Just as an FYI for the mailing list (I don't actually care about this): <br>
I needed to update on my machine CMake (I was previously running version <br>
3.6) to build CMake. This might be acceptable - but I figured that CMake <br>
should have used cmake_version_minimum to indicate the version I was <br>
using was not new enough. I did not investigate, but 3.6 bombed out with <br>
the following:<br>
<br>
C:\cmakegit\cmake\build> cmake .. -G "Visual Studio 14 2015 Win64"<br>
CMake Error at Tests/RunCMake/CMakeLists.txt:279 (if):<br>
   if given arguments:<br>
<br>
     "(" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL" <br>
"19.0.24215.1" "AND" "CMAKE_CXX_COMPILER_VERSION" "VERSION_LESS" "19.10" <br>
")" "OR" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL" <br>
"19.10.25017"<br>
<br>
   Unknown arguments specified<br></blockquote><div><br></div><div>This looks unintentional too. Recorded as <a href="https://gitlab.kitware.com/cmake/cmake/issues/18987">issue 18987</a>.</div><div><br></div><div> </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">
<br>
Nick Appleton<br>
<br>
On 2019-02-26 19:44, Craig Scott wrote:<br>
> If you're able to build CMake from sources yourself, you may want to<br>
> check if the changes from this merge request [2] are what has led to<br>
> the change you're seeing. That relates to how the EXCLUDE_FROM_ALL<br>
> target property is initialised when a target is created.<br>
> <br>
> On Tue, Feb 26, 2019 at 2:20 PM <<a href="mailto:nick@appletonaudio.com" target="_blank">nick@appletonaudio.com</a>> wrote:<br>
> <br>
>> 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>
>> <br>
>> generator. We've noticed most of our Visual Studio builds have<br>
>> started<br>
>> failing after switching to CMake 3.14.0-rc2 (not sure where betweenn<br>
>> <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<br>
>> 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<br>
>> 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<br>
>> INTERFACE_INCLUDE_DIRECTORIES<br>
>> "path to foo include files")<br>
>> set_property(TARGET fooN_cmake PROPERTY IMPORTED_LOCATION_DEBUG<br>
>> "path to<br>
>> foo static library")<br>
>> # ... more properties possibly set<br>
>> <br>
>> frontend1/CMakeLists.txt:<br>
>> <br>
>> add_subdirectory(../dependencies<br>
>> "${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<br>
>> "${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<br>
>> Visual<br>
>> Studio projects which are imported using include_extenal_msproject()<br>
>> <br>
>> that are dependencies of that particular frontend are included in<br>
>> the<br>
>> solution i.e. the VS solution for frontend1 will not include<br>
>> 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<br>
>> will<br>
>> all attempt to be built regardless of if there is a dependency. I<br>
>> would<br>
>> only have expected this behavior if EXCLUDE_FROM_ALL was *not* set<br>
>> when<br>
>> using add_subdirectory().<br>
>> <br>
>> Could someone help me to understand if the behavior change is<br>
>> expected<br>
>> or if this is just a bug?<br>
>> <br>
>> Thanks!<br>
>> <br>
>> Nick Appleton<br><br>
> <br>
> Links:<br>
> ------<br>
> [1] <a href="http://www.kitware.com" rel="noreferrer" target="_blank">http://www.kitware.com</a><br>
> [2] <a href="https://gitlab.kitware.com/cmake/cmake/merge_requests/2816" rel="noreferrer" target="_blank">https://gitlab.kitware.com/cmake/cmake/merge_requests/2816</a><br></blockquote></div><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></div>