[Buildroot] [PATCH 1/2] Add BR2_CMAKE_USE_NINJA_BACKEND option
Cédric Marie
cedric.marie at openmailbox.org
Thu Jan 26 17:27:36 UTC 2017
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
More information about the buildroot
mailing list