From: "Cédric Marie" <cedric.marie@openmailbox.org>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/2] Add BR2_CMAKE_USE_NINJA_BACKEND option
Date: Mon, 23 Jan 2017 14:39:45 +0100 [thread overview]
Message-ID: <2260e784237284271ff7745986b82cc8@openmailbox.org> (raw)
In-Reply-To: <ef982565-16ec-591b-aaed-d22e5a634851@gmail.com>
Hi,
Le 2017-01-21 23:25, Romain Naour a ?crit?:
> There are currently 146 packages using CMake in Buildroot, I'm not sure
> all of
> them support ninja backend yet.
I don't think there is anything specific to a package that can make it
support ninja backend or not.
CMake provides several backends, and the result is expected to be the
same whatever the backend. If not, this is a bug in CMake.
> I would suggest to enable Ninja backend package by package when it has
> been tested.
What do you mean exactly "enable Ninja backend package by package"?
- Add an option for each package?
- Switch to ninja backend if supported by the package, without option
(i.e. force ninja backend)?
- Keep a global option - the one in my patch - but only apply it on
packages that will define a specific package variable to say "OK I can
do it"?
My point of view is that we should keep a global option - that could be
described as experimental - and never enable it in an official
defconfig.
If someone enables it, and find a package that does not compile with
ninja backend, he can either disable the option (he knows that it is
experimental), or/and send a bug to either CMake or the package
maintainer.
Moreover, I think we can't just say "this package is ninja compliant".
Maybe if we change a single option in configure step, it will not
compile anymore.
Let me know what you're expecting exactly...
> Indent with one tab.
> Indent with one tab and 2 spaces.
OK, sorry for that, didn't pay enough attention.
> I think these changes should be in a preparatory patch before adding
> Ninja
> backend support.
Sorry I don't understand what you mean with "preparatory patch".
Regards,
--
C?dric
next prev parent reply other threads:[~2017-01-23 13:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 22:37 [Buildroot] [PATCH 1/2] Add BR2_CMAKE_USE_NINJA_BACKEND option Cédric Marie
2017-01-06 22:37 ` [Buildroot] [PATCH 2/2] Update documentation of CMake infrastructure Cédric Marie
2017-01-25 3:27 ` Thomas Petazzoni
2017-01-21 22:25 ` [Buildroot] [PATCH 1/2] Add BR2_CMAKE_USE_NINJA_BACKEND option Romain Naour
2017-01-23 13:39 ` Cédric Marie [this message]
2017-01-24 21:48 ` Romain Naour
2017-01-25 1:27 ` Thomas Petazzoni
2017-01-26 17:27 ` Cédric Marie
2017-01-30 9:23 ` Thomas Petazzoni
2017-02-01 17:01 ` Cédric Marie
2017-02-01 20:12 ` Thomas Petazzoni
2017-02-03 10:44 ` Cédric Marie
2017-01-25 1:37 ` Thomas Petazzoni
2017-07-11 11:56 ` Thomas Petazzoni
2017-07-11 13:25 ` Cédric Marie
2017-07-11 13:35 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2260e784237284271ff7745986b82cc8@openmailbox.org \
--to=cedric.marie@openmailbox.org \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox