Boost logo

Boost :

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at