Windows now uses ninja by default

[Scott Graham]

Hi,

http://crrev.com/243782 makes gclient create ninja build files instead of msvs projects by default.

If you haven't gotten on the ninja train yet, use "ninja -C out\Release chrome" to build. The binary ends up in out\Release.

If you build "ninja -C out\Debug chrome" instead, you can use "devenv.com /debugexe out\Debug\chrome.exe" to use Visual Studio to debug.

If ninja for some reason doesn't work for you, you can explicitly set the GYP_GENERATORS environment variable to "msvs" to switch back to VS. You can also set GYP_GENERATORS=ninja,msvs to make gyp generate both ninja build files and VS projects. Building with VS projects is no longer a tested configuration, however. If you have GYP_GENERATORS set to ninja, you could consider no longer setting GYP_GENERATORS since ninja is now the default.

This change had some of the trickiness of the Mac change because the output directory moved from "build" to "out". Fortunately, Nico did a lot of hard work related to this when switching Mac, and Windows benefited from that. However, if you see anything weird related to build directories, please let me know.

Scott

PS. This means that official chrome builds are now built using ninja too (assuming the change sticks).

[Daniel Bratell]

On Thu, 09 Jan 2014 09:45:27 +0100, Scott Graham <sco...@chromium.org>
wrote:

> Hi,
>
>> http://crrev.com/243782 makes gclient create ninja build files instead
>> of msvs projects by default.

Nice.

Is the msvs-ninja generator still around too? With
GYP_GENERATORS=ninja,msvs-ninja you get/got a VS project so you could work
inside MSVS and it would trigger ninja when you asked for a build. Kind of
the best of both worlds.

/Daniel

[Nico Weber]

The only thing that changed (for now) is the default value of GYP_GENERATORS on Windows. If you manually set GYP_GENERATORS to something, nothing will change for you.

(I expect that msvs-ninja will stay functional for the foreseeable future, while building chromium with the 'msvs' generator will probably bitrot eventually.)

 

/Daniel

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

[Gabriel Charette]

Last I heard ninja still had issues with properly embedding Windows manifests in generated binaries, was this addressed?

[Scott Graham]

Yes, this was part of crbug.com/326030.

[Gabriel Charette]

On Thu, Jan 9, 2014 at 11:38 AM, Scott Graham <sco...@chromium.org> wrote:

Yes, this was part of crbug.com/326030.

Oh awesome, I didn't notice that bug had been fully fixed :)!

Cheers!

Gab

[Gabriel Charette]

Also, with VS static (non-component) builds it was previously recommended to not use incremental_chrome_dll=1 and chromium_win_pch=1 as is recommended in ninja.

Is it okay to now use incremental_chrome_dll=1 and chromium_win_pch=1 to build static builds with ninja (seems to work...)?

From local experimentation it also appears that manifests are embedded in static builds, but left as external manifests in component builds, any reason why?

[Scott Graham]

You don't need to set incremental_chrome_dll=1 or chromium_win_pch=1, they're on by default when it makes sense.

Manifest embedding is controlled by https://code.google.com/p/chromium/codesearch#search/&q=win_use_external_manifest&sq=package:chromium&type=cs . Previously, embedding manifests broke incremental linking so it was off for debug/dev builds, but that should no longer be an issue after https://code.google.com/p/gyp/source/detail?r=1813 . So, we can probably move to all-embedded now if that's useful.

[Gabriel Charette]

On Thu, Jan 9, 2014 at 3:50 PM, Scott Graham <sco...@chromium.org> wrote:

You don't need to set incremental_chrome_dll=1 or chromium_win_pch=1, they're on by default when it makes sense.

Manifest embedding is controlled by https://code.google.com/p/chromium/codesearch#search/&q=win_use_external_manifest&sq=package:chromium&type=cs . Previously, embedding manifests broke incremental linking so it was off for debug/dev builds, but that should no longer be an issue after https://code.google.com/p/gyp/source/detail?r=1813 . So, we can probably move to all-embedded now if that's useful.

That would indeed be useful, it will allow me to remove some of the hacks I put in the codebase to have the installer work with the component build.

Cheers,

[Zachary Turner]

FWIW I've been using the installer with the component build for a while now, and I've never had a problem and don't use any hacks.  But it's possible you're doing different things with the installed product than I am, which is causing the difference.

[Gabriel Charette]

Me too, and I can tell you for sure that you are using (without knowing) the manifests hacks which I added to create_installer_archive.py for the installed chrome to work in a component build.

We were previously using the fact that they were external manifests to augment them and do even more magic, but we just switched to a different method (involving the version assembly manifest introduced for chrome_elf; which now means the component build installer works on XP!) which is such that the only thing to do with chrome.exe.manifest and setup.exe.manifest is to copy them as-is (since the archive script, designed to operate on static builds, doesn't know about them) -- we could remove those explicit copy tasks if the manifests were embedded and make the developer build one step closer to the one we ship.

Less configuration-specific hacks FTW.

Cheers,

Gab

[Peter Kasting]

On Thu, Jan 9, 2014 at 12:45 AM, Scott Graham <sco...@chromium.org> wrote:

If you haven't gotten on the ninja train yet, use "ninja -C out\Release chrome" to build. The binary ends up in out\Release.

If you build "ninja -C out\Debug chrome" instead, you can use "devenv.com /debugexe out\Debug\chrome.exe" to use Visual Studio to debug.

I just updated to this configuration and am trying to use ninja for the first time.

From a cygwin shell, "ninja -C out/Debug chrome" gives:

ninja: Entering directory `out/Debug'

ninja: error: 'gen\repack\chrome_touch_100_percent.pak', needed by 'chrome_touch_100_percent.pak', missing and no known rule to make it

I also get this error running "ninja -C out\Debug chrome" from a cmd shell.

I tried adding the "msvs-ninja" generator and opening MSVC on chrome/chrome.sln, and building from there, and got the same error yet again.

What am I doing wrong?

PK

[Nico Weber]

What are your gyp defines?

--

[Scott Graham]

Could you try running gclient runhooks from cmd rather than cygwin?

[Peter Kasting]

On Thu, Jan 16, 2014 at 1:33 PM, Scott Graham <sco...@chromium.org> wrote:

Could you try running gclient runhooks from cmd rather than cygwin?

Done, but didn't seem to have any effect.

On Thu, Jan 16, 2014 at 1:33 PM, Nico Weber <tha...@chromium.org> wrote:

What are your gyp defines?

I have a ~/.gyp/include.gypi with:

{

  'variables': {

    'component': 'shared_library',

    'disable_nacl': 1,

    'disable_pnacl': 1,

  }

}

Is that what you wanted to know?

PK 

[Gabriel Charette]

Feels like it's trying to build branding=Chrome without src-internal; is that possible?

--

[Zachary Turner]

Do you have a chromium.gyp_env one level above src/ as well?  

--