using ninja instead of make
jonesc at hep.phy.cam.ac.uk
Fri Jan 2 11:49:22 PST 2015
> On 1 Jan 2015, at 10:16 pm, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Thursday January 01 2015 22:38:32 Clemens Lang wrote:
>> The only configuration system (of relevant size and adoption) that falls into this
>> category is CMake. We could use ninja instead of make for all CMake ports, but
> That's what I had in mind.
>> orders of magnitude faster) than make when build times are largely dominated by
>> the compile times itself, rather than the execution time of the build tool.
> I must admit that I share your scepticism, but I've been seeing too many comments to the contrary lately that I'm getting interested to try things out.
Ninja is possibly of interest to developers, who repeatedly (re)build packages during development, as ninja is a bit quicker at figuring out what needs rebuilding etc. For a single from scratch build there will be essentially no benefit, so do not expect replacing make with ninja to help much with a normal port build.
> As you said, this would be in conjunction with CMake, which also happens to generate Makefiles that are very verbose. That adds considerable overhead (esp. with the long path names courtesy of MacPorts' build directory), which could well exceed the time required for the actual destroot step.
>>> 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.
I suspect that would be a bad idea, given most packages will not be tested against ninja. If done at all, it should be done on a port by port basis once that port has been properly tested. However, QI still very much doubt there is much to be gained for 'normal' port builds.
> macports-dev mailing list
> macports-dev at lists.macosforge.org
More information about the macports-dev