Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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