Ok, so it all seems to boil down to the following:
- 2.8.12: "cmake --build" uses devenv to build, which in turn picks
up a setting ("maximum number of parallel project builds") from the VS
IDE at build time. As this was set to 8 on my machine, by default the
build used parallellization with 8 cores with a fast parallel build as
a result. I verified that after changing this setting in the IDE to 1,
the build no longer works in parallel, with longer build times as a
result.
- 3.x: "cmake --build" uses MSBuild, which uses a command line switch
/m to control the same behavior. In absence of this command line
switch, the default behavior is equivalent to /m1 (see
https://msdn.microsoft.com/en-us/library/ms164311.aspx), which means a
non-parallel build and longer build times than for 2.8.12. A way to
test this in practice, is to run a build command with native build
options like 'cmake --build . --config Release -- /m'. I checked and
this indeed works as expected.
The above explains all my initial observations. However, the fix is
not very handy. As I understood, one does not know until build time
what exact build (devenv or msbuild) will be used by CMake, so simply
always adding '-- /m' to the build command will not work (devenv
doesn't like /m). Assuming that changing the default command line
options to MSBuild inside CMake is not a valid solution, I am
wondering if there is currently a way to set additional build options
for MSBuild only from inside the CMakeLists.txt file? Or,
alternatively, is there a way to check which build program will be
used before actually running the build?
Yves
On Tue, Jan 20, 2015 at 10:46 PM, Paul Smith <p...@mad-scientist.net> wrote:
> On Tue, 2015-01-20 at 16:02 -0500, Paul Smith wrote:
>> > I think devenv is used instead of msbuild when the solution has
>> > fortran projects.
>>
>> I certainly don't have any Fortran projects--!!
>
> I think I figured it out: on our build servers we don't delete
> everything and start over from scratch all the time (only for our
> official release builds).
>
> We recently upgraded our cmake from 2.8.12.2 to 3.1.0 and I think that
> the systems where we were seeing this problem had CMakeCache.txt files
> left over from when we were using CMake 2.8.12.2, and those files had
> CMAKE_MAKE_PROGRAM set (we never set it by hand, even back then, but
> maybe the older version of cmake added it to the cache on its own?) to
> devenv.
>
> Certainly when I went in and looked at CMakeCache.txt that value was set
> to "devenv.exe". If I regenerated the CMakeCache.txt from scratch, it
> was no longer set.
>
> --
>
> 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
--
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
