Re: [boost] Switch to CMake -- Analysis

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 [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