On 01/21/2015 11:00 AM, Hendrik Sattler wrote: > This makes cmake --build much less predictable across cmake versions and > cmake projects. > How can I find out if msbuild is chosen without inspecting the cmake project?
One can't, but that is a fault of VS and/or Intel Fortran for having cases that require devenv or msbuild, not a fault of CMake for trying to deal with it. Since 3.0 we always picks msbuild unless Fortran is involved. This is fairly predictable moving forward. > - get the CMAKE_VS_MSBUILD... from cache and at set CMAKE_MAKE_PROGRAM from > it. > > @Paul: You can probably modify the CMAKE_VS_MSBUILD... variable to add /m. The CMAKE_VS_MSBUILD_COMMAND variable: http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_VS_MSBUILD_COMMAND.html is not cached. It is available to CMakeLists.txt code. > But to compile in parallel should be s decision of the user, not the > project, and thus a decision of the caller of cmake --build. Rather than requiring users to run cmake --build . -- $tool_specific_parallel_option to get a parallel build we could instead extend the "cmake --build" command to support an option mapping to the right parallel option underneath: cmake --build . --parallel cmake --build . --parallel=$n -Brad -- 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: http://public.kitware.com/mailman/listinfo/cmake
