On 19/03/2015 16:02, Ben Boeckel via Digitalmars-d-announce wrote:
It might force to think of your build components in a more
>structured/componentized way, instead of the paradigm of building on a
>file by file basis, the `make` way. (I've only used make though, not
>cmake, so dunno how much this comment applies to the later)
Building file-at-a-time is, for developers, on the whole faster than
"unity" builds because you can parallelize it and only have to build
what changed.
CMake only really works with .d -> .o rules (Java support bends this
AFAIK due to restrictions in javac, but I vastly prefer -j8 over a
single invokation).
I think the issue of speed and parallellization is an orthogonal one:
The build components should be structured in properly defined,
self-contained, versioned libraries/bundles(*) - that can be built, and
auto-tested on their own (obviously using the dependencies they require
too). That should be the primary (top level) build unit of a build system.
But, the way you build each bundle/component, is still up to the build
system. You can build it on file-by-file sequentially, or parallelized, etc.
I'm not familiar with CMake, so I don't know if it has any concept
similar to this, but I suspect not.
*: AKA "packages" in DUB and Ruby, "crates" in Rust.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
