[Buildroot] [PATCH 1/2] Add BR2_CMAKE_USE_NINJA_BACKEND option

["Cédric Marie" <cedric.marie@openmailbox.org>]

Hi Romain, Thomas, and all,

Le 2017-01-24 22:48, Romain Naour a ?crit :
> Yes, something like that but It's just a proposal...
> 
> <package>_SUPPORT_NINJA_BACKEND = YES in the .mk
> (with default to N0)
> 
> ifeq ($(BR2_CMAKE_USE_NINJA_BACKEND),y)
> ifeq ($$($(2)_SUPPORT_NINJA_BACKEND),YES)
> $(2)_CONF_OPTS += -G Ninja
> $(2)_DEPENDENCIES += host-ninja
> endif
> endif

Yes, that could be a good solution to use ninja whenever possible and 
keep other few packages compiling with make backend.

> So, yes Ninja is slightly faster than Make.
> It would be great if you can add some test results in the commit log.

OK, I can do that.


Le 2017-01-25 02:27, Thomas Petazzoni a ?crit?:
> But then that's a bit annoying because we would have to explicitly
> set this option to "YES" on all packages that support the Ninja backend
> (most likely the majority).
> 
> I think it would make more sense to default the other way around, i.e
> default to YES, and set it to NO on the few packages that do not
> properly support the Ninja backend.
> 
> Or maybe better: do not introduce a per-package option for the moment,
> have only the global one, see in practice how many packages work /
> don't work and decide if we need a per-package option, and what default
> value it should have.

OK, but it seems that Romain has already noticed a problem with 
openpowerlink, so it is likely that this option will be necessary - and 
hopefully default to YES (supported).

> So we're saving between 1 and 2 seconds of build time, while host-ninja
> requires building host-python or host-python3 ?
> 
> Seeing those numbers, the whole thing seems really pointless to me.
> You're saving 1-2 seconds of build time, but you've got a full Python
> interpreter to build.
> 
> Would it be possible to get numbers on the overall build time showing
> what Ninja is improving?

Yes, you're right. Unless we use python and ninja from the host if 
available, instead of compiling them, but this is not the right solution 
I suppose (although this is done for CMake!...).

I agree that a few seconds are not much!... And I agree that we are 
loosing much more time to compile host packages.

So, why did I want to introduce this option?

Because I'm not using Buildroot in one-shot mode. I'm developping in a 
Buildroot environment. So I often make foo-rebuild my package, and I'm 
interested in saving time for each rebuild.

I know this is not what Buildroot is designed for. (Yet, there are a few 
things that seem to be present for dev mode (rsync with OVERRIDE_SRCDIR 
for example), so this is not "pure one-shot" either.)

In conclusion, I would say that this option is useful to me - not much, 
just for a few seconds - but maybe makes no sense for buildroot 
upstream, since it increases build time.

It's up to you. I won't be offended if the patch is refused. I don't 
want to introduce something that will break Buildroot philosophy.

Regards,

-- 
C?dric