Subject: Re: [boost] Switch to CMake -- Analysis
From: Ion GaztaÃ±aga (igaztanaga_at_[hidden])
Date: 2017-07-24 20:18:09
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  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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk