Re: [boost] Switch to CMake -- Analysis

Subject: Re: [boost] Switch to CMake -- Analysis
From: paul (pfultz2_at_[hidden])
Date: 2017-07-24 20:43:13

On Mon, 2017-07-24 at 22:18 +0200, Ion Gaztañaga via Boost wrote:
> 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. 

The configuration is only ran once, initially, and doesn't take considerable
time.

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

Yea, no one is talking about copying the sources. This is about multiple build
directories, but the source tree is the same.