On 24/07/2017 16:08, Tim Blechmann via Boost wrote:
Just to disagree, I think it's a deficiency (one of the biggest one) of CMake because CMake, as a "build" tool, does not support parallel builds because it depends on other build tools, including bad ones. I really don't understand why CMake can't build things directly, it's one of its biggest deficiencies.
One of the most important requirements of a build tool is to build software *fast* and *portably*, without having to rely on other programs.
fwiw, systems like ninja [1] are designed to support fast and parallel builds, the syntax is designed for that use-case, and it is designed to be generated (by cmake or gyp).
otoh, fast compile times are not necessarily the only requirement: parallel builds with ninja render windows unresponsive, so it are much more suited for buildservers (macos is better, linux doesn't have this issues). so as developer your productivity may be lower, even if the compile times are faster.
I usually run my library tests for dozens of configurations with a script that is launched with lower than normal priority and with -jN with N being 1.5 times the number of CPUs (I find compiling is many times IO-bounded). At least with a SSD disk, I can still do my low-cpu tasks like e-mail and browsing without any problem. I'm using windows, no idea if other OS/desktops have that problem. I wasn't talking about a build system that freezes your computer, but something that builds in parallel and always builds similarly in every OS. I'm afraid that if i need to have a different "build folder" for each configuration, project/make/ninja generation will take a considerable time that could be used just to compile and run my tests. Of course I don't consider any option that would force me to copy sources (say, the boost tree) to a different sandbox to avoid project/make/ninja generation conflicts, that would be simply crazy.
otoh, developers who like IDEs may have a higher productivity due to debugger integration.
Sure. At least in windows you can open an executable as a project with Visual Studio and debug it flawlessly. If there is a problem with a Boost.Build test, I can just drop the exe into the IDE and debug it without problems, if it has debug info (and in my local tests I activate debug symbols also in release, just in case). For Linux gdb -tui is what I use. Best, Ion