On Tue, Feb 26, 2019 at 10:06 PM <n...@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 <n...@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/>
--
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
