On Friday January 02 2015 09:53:32 Mojca Miklavec wrote: > >>> How would one set things up for this? > >> > >>Modify the CMake PortGroup to use ninja. > > > > Basically by adding "-G ninja" to the configure.args, and then modify the > > variables defining the make application and arguments? I'd do that first in > > a test port rather than imposing it on every port depending on CMake. > > If you manage to do that, please test it with Geant4 and Clang. Those > need quite some time to build, so at least you should get some real > differences (if differences can be expected).
>From the lldb-dev ML: Re: [lldb-dev] MSBuild vs. Ninja build-timings on Windows From: Nico Weber <thakis@> To: "[email protected]" <[email protected]> Date: 20150104 02:42 For why ninja is faster than other build systems, it depends if you look at full or incremental builds. For full builds, build speed is mostly related to how many compile processes can be run in parallel. Many build systems add a "target" abstraction and then do scheduling at a target level, which means if a static library depends on another static library, all translation units in the first static library have to be compiled first and then linked into a static library before any compilation in the second library can start. Since compiling source files can't depend on a static library being present or not, this is an artificial limitation that needlessly serializes the build. Ninja only gets a description of the build graph, and cmake is smart enough to write build graph descriptions that do not make compiles of a downstream target depend on an upstream static library, for example. For incremental builds, ninja is fast because it does less: It only reads build manifests and header deps (which are written into a single deps log at build time, so it's only a single file to read), stats all input files, and does nothing else. Other systems often have an imperative (instead of a declarative) build description and run some scripts on every build unconditionally, they read and write ancillary files, and so on. Nico _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
