CI: unify the way to set parallel build

[illwieckz]

Let's see if it works for AppVeyor/MSVC, and if the same builder-agnostic method also works on other systems.

[illwieckz]

It doesn't seem to be faster on AppVeyor, maybe there is only 1 core?

[illwieckz]

Appveyor allocates only 2 cores:

set CMAKE_BUILD_PARALLEL_LEVEL=%NUMBER_OF_PROCESSORS%
echo %CMAKE_BUILD_PARALLEL_LEVEL%
2

[illwieckz]

It doesn't seem to be faster on AppVeyor.

On macOS I had to set the variable with export to get it working, but there is no export on Windows.

[illwieckz]

All I save with Appveyor/MSVC is 30s… 😐️ We basically go from 8m40 to 8m10 for a single build. It's always welcome, but I as hoping more.

[illwieckz]

I moved out of the appveyor script the commenst, to avoid those errors:

The system cannot find the file specified.

Both the standard REM remark (comment) command and the label-hijacked-hack :: produce this error.

[illwieckz]

The idea of overloading a bit the CPU cores is that it usually allows to save some time because both the compiler and the build system (CMake, make, etc.) may not use 100% of the CPU when doing something. This usually works with 1 or 2 more jobs than cpu cores (overloading too much may put the memory and the scheduler on pressure and start being counter-productive).

[slipher]

If the CMake parallelism turns out to do anything, it would be nicer to use the --parallel option of cmake --build rather than an environment.

We already insert /MP in MSVC builds because it is needed to make Visual Studio build in parallel so I wouldn't expect adding it again to change anything.

[slipher]

NMake apparently doesn't have a -j equivalent so that part will probably be a no-op from CMake as well. https://stackoverflow.com/questions/601970/how-do-i-utilise-all-the-cores-for-nmake

[illwieckz]

We already insert /MP in MSVC builds because it is needed to make Visual Studio build in parallel so I wouldn't expect adding it again to change anything.

Ah right, that's why I see so fee differences.

If the CMake parallelism turns out to do anything

It looks like it helps at doing cmake things in parallel like generating the .h from glsl files while building other things.

[slipher]

If the CMake parallelism turns out to do anything

It looks like it helps at doing cmake things in parallel like generating the .h from glsl files while building other things.

I don't think so, AFAIK CMake is strictly single-threaded. The way this is expected to work is that the generated build system (Make/VS/etc.) shells out to CMake script mode each time it generates one of those files. So the generated build system controls the parallelism.

[illwieckz]

Whatever what is parallelized, I got this here:

  dummyapp.vcxproj -> C:\projects\daemon\build\Release\dummyapp.exe
  files.cpp
  huffman.cpp
  msg.cpp
  net_chan.cpp
  Generating embed_data/vertexSkinning_vp.glsl.h
  net_ip.cpp
  gmock.vcxproj -> C:\projects\daemon\build\lib\Release\gmock.lib
  translation.cpp
  sv_bot.cpp
  Generating embed_data/vertexSprite_vp.glsl.h
  sv_ccmds.cpp
  sv_client.cpp
  sv_init.cpp
  sv_main.cpp
  sv_net_chan.cpp
  sv_sgame.cpp
  sv_snapshot.cpp
  CryptoChallenge.cpp
  Generating embed_data/blurX_fp.glsl.h
  NullKeyboard.cpp
  null_client.cpp
  null_input.cpp
  Building Custom Rule C:/projects/daemon/CMakeLists.txt

[slipher]

I was wrong to say the generator is NMake. Nmake is used for the NaCl secondary build when part of a Visual Studio build, but we don't test that on CI. So the generator is Visual Studio, the same as for the IDE project.

What I said about /MP is still true though, so I doubt there are any improvements to be had.