Linux now uses ninja by default

[Nico Weber]

Hi,

I just landed r199603, which lets gclient create ninja build files instead of makefiles by default. Assuming it sticks: If you're building on linux and haven't switched to ninja yet, just run `ninja -C out/Debug` instead of `make` to build. Nothing else should change.

If ninja for some reason doesn't work for you, you can explicitly set the GYP_GENERATORS environment variable to "make" to switch back to make. If you do this, please tell me why.

My change only changed the default generator; if you're explicitly setting some generator the change does not affect you.

Nico

ps: This means that official chrome builds are now built using ninja too (again, assuming the change sticks).

[Nico Weber]

It looks like this might stick. I've updated the LinuxBuildInstructions wiki page accordingly. If you see any other wiki pages that still mention make, please help updating them.

Thanks!

Nico

[Marc-Antoine Ruel]

Thanks a lot for taking care of this, this is appreciated. Once this got out to stable in ~3 months, we should look at officially ditching support for make on OSX and Linux, since both are now untested.

Anyone disagree?

M-A

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 
 

[Nico Weber]

On Wed, May 15, 2013 at 2:55 PM, Lambros Lambrou <lambros...@chromium.org> wrote:

I believe, on OS X, the Chromoting Host component still needs "make" to build its System Preference Pane as a Universal Binary plugin. Last time I checked (a long time ago), ninja only built this as a 32-bit plugin. If a user tried to load such a plugin into System Preferences, it would prompt with "System Preferences needs to close and restart...", which harms the UX for Chromoting on Mac.

Nico, do you know if recent ninja changes will make it possible to have this working? We use 'ARCHS': ['i386', 'x86_64'] to achieve this build (see remoting/remoting.gyp:remoting_host_prefpane). This also means our PrefPane cannot at present link with any Chrome code, which is a limitation we'd certainly like to remove :)

It is true that ninja can't do multi-arch builds on OS X yet, but make can't either. The Chromoting Host needs to be built with xcode. I believe make hasn't been working on OS X for a while now (and it wasn't needed: The advantage of the make build on OS X over the xcode build was that it was faster, and ninja is faster still).

[Lambros Lambrou]

I believe, on OS X, the Chromoting Host component still needs "make" to build its System Preference Pane as a Universal Binary plugin. Last time I checked (a long time ago), ninja only built this as a 32-bit plugin. If a user tried to load such a plugin into System Preferences, it would prompt with "System Preferences needs to close and restart...", which harms the UX for Chromoting on Mac.

Nico, do you know if recent ninja changes will make it possible to have this working? We use 'ARCHS': ['i386', 'x86_64'] to achieve this build (see remoting/remoting.gyp:remoting_host_prefpane). This also means our PrefPane cannot at present link with any Chrome code, which is a limitation we'd certainly like to remove :)

On Wed, May 15, 2013 at 2:38 PM, Marc-Antoine Ruel <mar...@chromium.org> wrote:

[Lambros Lambrou]

On Wed, May 15, 2013 at 2:59 PM, Nico Weber <tha...@chromium.org> wrote:

On Wed, May 15, 2013 at 2:55 PM, Lambros Lambrou <lambros...@chromium.org> wrote:

I believe, on OS X, the Chromoting Host component still needs "make" to build its System Preference Pane as a Universal Binary plugin. Last time I checked (a long time ago), ninja only built this as a 32-bit plugin. If a user tried to load such a plugin into System Preferences, it would prompt with "System Preferences needs to close and restart...", which harms the UX for Chromoting on Mac.

Nico, do you know if recent ninja changes will make it possible to have this working? We use 'ARCHS': ['i386', 'x86_64'] to achieve this build (see remoting/remoting.gyp:remoting_host_prefpane). This also means our PrefPane cannot at present link with any Chrome code, which is a limitation we'd certainly like to remove :)

It is true that ninja can't do multi-arch builds on OS X yet, but make can't either. The Chromoting Host needs to be built with xcode. I believe make hasn't been working on OS X for a while now (and it wasn't needed: The advantage of the make build on OS X over the xcode build was that it was faster, and ninja is faster still).

 

My mistake - I forgot we used xcode, not make, for the OS X pref-pane. So there's no problem for us with ditching make. Thanks for clarifying!

Lambros

[Matthew Dempsky]

On Wed, May 15, 2013 at 2:38 PM, Marc-Antoine Ruel <mar...@chromium.org> wrote:

Thanks a lot for taking care of this, this is appreciated. Once this got out to stable in ~3 months, we should look at officially ditching support for make on OSX and Linux, since both are now untested.

Anyone disagree?

Just curious, does "officially ditching support" mean dropping the make backend from gyp, or does it just mean if people try building Chromium with make and something goes wrong, it's up to them to fix it?

[Robert Iannucci]

I would expect the latter. I don't know if there's compelling reason to remove Make support from gyp (i.e. there may be, but I don't know what it is).

--

[Marc-Antoine Ruel]

As Robert said, I meant not officially supporting make to build chromium, I didn't imply touching gyp at all.

I meant from a CI perspective ignoring make for build purposes.

M-A

2013/5/15 Robert Iannucci <iann...@chromium.org>

[Nico Weber]

On Wed, May 15, 2013 at 5:02 PM, Matthew Dempsky <mdem...@google.com> wrote:

There's no reason to remove the make backend from gyp I think, but we're going to be less interested in implementing new features for it. For perspective, the chromium linux build uses to use scons for a while, and we kept the gyp's scons backend around for over 2 years even though nobody seemed to use it for anything. Make is a lot more popular than scons.

Nico

[Paweł Hajdan, Jr.]

This is not a disagreement, but a comment about the implementation.

Can we get a mapping between version of Chrome and version of ninja (version, not a random revision, i.e. a tag and not just sha) needed to build that version of Chrome?

While make is ubiquitous on Linux systems, ninja isn't, and I can imagine things easily getting out of sync with rapid development of ninja. Getting the binary blob from versionless depot_tools is not an acceptable solution (I can explain in more detail why if this is not obvious; short story is: repeatable builds).

Note that I'm all for faster builds, just wanted to make sure the build process remains sane for third parties.

Paweł

On Wed, May 15, 2013 at 2:38 PM, Marc-Antoine Ruel <mar...@chromium.org> wrote:

[Nico Weber]

On Thu, May 16, 2013 at 4:00 PM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

This is not a disagreement, but a comment about the implementation.

Can we get a mapping between version of Chrome and version of ninja (version, not a random revision, i.e. a tag and not just sha) needed to build that version of Chrome?

The ninja binaries in depot_tools are always official ninja releases, currently ninja 1.1. To build a given revision of chromium, a ninja binary with at least the release number in depot_tools is needed. Recently, the binary seems to get bumped every 4 months or so: http://src.chromium.org/viewvc/chrome/trunk/tools/depot_tools/ninja-linux64?view=log

Since depot_tools is needed for checking out chrome, running just `ninja` will either run the right binary, or print instructions on how to get the right binary: http://src.chromium.org/viewvc/chrome/trunk/tools/depot_tools/ninja (though it looks like I forgot to update the tag in that file 4 months ago).

Nico

[ev...@chromium.org]

Ninja now supports specifying which version of Ninja the build files require.  This makes the version dependency explicit (and Ninja will abort with a nice error message if your version is too old).

For more, see:

  http://martine.github.io/ninja/manual.html#ref_versioning

We should make gyp pass the appropriate value.  Then the dependency by Chrome remains just about which version of gyp it uses.

[Paweł Hajdan, Jr.]

Evan, that sounds good.

How will you ensure that version number in the generated ninja files stays up to date?

One more thing: are there any stable (as in contents do not change) ninja tarballs available for download somewhere? I remember github tarballs used to have different contents between downloads, which prevents checksumming the tarball.

Paweł

[Evan Martin]

On Mon, May 20, 2013 at 10:29 AM, Paweł Hajdan, Jr.
<phajd...@chromium.org> wrote:
> How will you ensure that version number in the generated ninja files stays
> up to date?

That's up to the people who make changes in Gyp.
In practice, that is Nico. :)

> One more thing: are there any stable (as in contents do not change) ninja
> tarballs available for download somewhere? I remember github tarballs used
> to have different contents between downloads, which prevents checksumming
> the tarball.

I just downloaded https://github.com/martine/ninja/tarball/v1.3.3
twice and got the same sha1sum from both files. Maybe they fixed
their bug.

(I constructed that URL from reading
https://fedorahosted.org/fpc/ticket/284 , not sure if there's a more
canonical form.)

[Nico Weber]

On Mon, May 20, 2013 at 10:40 AM, Evan Martin <ev...@chromium.org> wrote:

On Mon, May 20, 2013 at 10:29 AM, Paweł Hajdan, Jr.
<phajd...@chromium.org> wrote:
> How will you ensure that version number in the generated ninja files stays
> up to date?

That's up to the people who make changes in Gyp.
In practice, that is Nico.  :)

Pawel, did you see anything wrong with what I said in my response? I hadn't planned on letting gyp write ninja_required_version at this point. (The reasoning being that the right ninja should already be in depot_tools anyhow so it doesn't really buy us anything, and it's not clear what effect it will have if ninja ever goes to 2.0. So it adds some risk without adding any benefits.)

(Since this is fairly technical, maybe future discussion of this topic could be off-list?)

Nico

[Paweł Hajdan, Jr.]

Nico, it's fairly close - still, here are questions I have about it:

1. How do you ensure the ninja version in help string stays accurate?

2. How do you know which depot_tools version corresponds to which Chrome version? More directly, which ninja version to which Chrome version?

These two things are more important to me than ninja_required_version, which I consider one of many possible implementations (and the question of keeping it up to date still remains).

Paweł