GYP-to-GN transition policy and update

[Brett Wilson]

TL;DR: Please R, the details here will affect all developers.

🆕

Android and Linux are approaching GN completeness.

Very shortly, we will stop running GYP as a gclient hook for these configurations. After this happens, you can still run GYP manually if you want "python build/gyp_chromium.py" assuming it still works (see below).

In the next week, we'll finish flipping over all the bots for these configurations. As we flip configurations over to GN, the bots on the waterfall will represent the current state of GYP support. If there is a GYP bot on the waterfall, we need to support the GYP build for that configuration. If there is no GYP bot, the GYP build will be unsupported on that configuration.

We'll remove GYP files specific to unsupported configurations as we go (they'll bitrot immediately anyway). If you are a Googler compiling the official Android build, you will be affected by this first as there are currently no official Android bots and there are a few .gyp files specific to this build.

🎵Important notes

- The GYP_DEFINES environment variable is still hooked up to control a few things in gclient like the downloading of Android libraries when OS==android. Don't assume you can delete GYP_DEFINES yet (the component flag is not used: if this is all you have it's safe to delete). Long-term, we need to figure out a better way to control these steps, but this is lower priority (please help!).

- When a configuration is unsupported, you should not feel obligated to keep GYP in sync with GN or even building. Code reviewers should not require this.

🆙 What's next

We will post updates as important classes of things become unsupported. Windows and ChromeOS will follow Android and desktop Linux. If you still use GYP for any of these platforms, you should switch to GN right away. If something doesn't work for you, we either need to know about it or you need to fix it ASAP.

Mac and iOS developers should continue using GYP for now (but not for long).

🆘 Quick start

cd mycheckout/src

gn gen out/foo  [Don't use "Debug" or "Release", you only need to do this once]

ninja -C out/foo chrome

Email gn-...@chromium.org for questions.

Thanks!

[Sunny Sachanandani]

> - The GYP_DEFINES environment variable is still hooked up to control a few things in gclient like the downloading of Android libraries when OS==android. Don't assume you can delete GYP_DEFINES yet (the component flag is not used: if this is all you have it's safe to delete). Long-term, we need to figure out a better way to control these steps, but this is lower priority (please help!).

I thought this was controlled by the "target_os = ['android']" line in the .gclient file and not by GYP_DEFINES.

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

[Dirk Pranke]

On Tue, Apr 26, 2016 at 6:28 PM, Sunny Sachanandani <sun...@chromium.org> wrote:

> - The GYP_DEFINES environment variable is still hooked up to control a few things in gclient like the downloading of Android libraries when OS==android. Don't assume you can delete GYP_DEFINES yet (the component flag is not used: if this is all you have it's safe to delete). Long-term, we need to figure out a better way to control these steps, but this is lower priority (please help!).

I thought this was controlled by the "target_os = ['android']" line in the .gclient file and not by GYP_DEFINES.

I think this particular example is a little confusing, in that most if not all of the android libraries are pulled in via target_os, as you say.

However, there are other places that are still sensitive to GYP_DEFINES, like which sysroots are downloaded, so Brett's still generally right.

-- Dirk

[Andrew Grieve]

On Tue, Apr 26, 2016 at 9:50 PM, Dirk Pranke <dpr...@chromium.org> wrote:

On Tue, Apr 26, 2016 at 6:28 PM, Sunny Sachanandani <sun...@chromium.org> wrote:

> - The GYP_DEFINES environment variable is still hooked up to control a few things in gclient like the downloading of Android libraries when OS==android. Don't assume you can delete GYP_DEFINES yet (the component flag is not used: if this is all you have it's safe to delete). Long-term, we need to figure out a better way to control these steps, but this is lower priority (please help!).

I thought this was controlled by the "target_os = ['android']" line in the .gclient file and not by GYP_DEFINES.

I think this particular example is a little confusing, in that most if not all of the android libraries are pulled in via target_os, as you say.

However, there are other places that are still sensitive to GYP_DEFINES, like which sysroots are downloaded, so Brett's still generally right.

-- Dirk

The bug tracking this particular quirk is: https://bugs.chromium.org/p/chromium/issues/detail?id=570091

I think (at least for Android), you are fine to not have any GYP_DEFINES set. If you come across a place that still relies on it, please point it out on the bug.

[Anthony Berent]

One thought; many of us (at least those most of us working on Chrome for Android) only have easy access to Linux machines, so can't easily run local Windows or Mac builds. As such, when we make changes that update target independent GYP files, the only way to test these locally is to do a local Android or Linux build. Please keep the Linux GYP build alive until all targets have moved to GN, and we can stop supporting the target independent parts of GYP files.

[Brett Wilson]

On Wed, Apr 27, 2016 at 2:44 AM, Anthony Berent <abe...@chromium.org> wrote:

One thought; many of us (at least those most of us working on Chrome for Android) only have easy access to Linux machines, so can't easily run local Windows or Mac builds. As such, when we make changes that update target independent GYP files, the only way to test these locally is to do a local Android or Linux build. Please keep the Linux GYP build alive until all targets have moved to GN, and we can stop supporting the target independent parts of GYP files.

I can't think of Linux-specific .gyp files that we expect would be deleted so I don't expect that this will be purposefully removed in the immediate future. ChromeOS still uses GYP in some says and that's "mostly Linux." But almost no bots run non-ChromeOS Linux GYP and shortly that will be actually zero. So if you're depending on it working in any particular way for this purpose, you're already on thin ice. Once ChromeOS switches over, we'll be able to drop all non-Mac Posix support in GYP which will be a big improvement in terms of build-support tax.

Doing what you really want requires us to have Linux bots running and requiring the entire team to maintain the desktop Linux build specifically for this use case. I don't think this is actually a net win on team productivity. Most build changes are straightforward (adding and removing files), and many non-straightforward things are platform-specific anyway (conditions).

But I can certainly see how some things will be annoying in some cases. Hopefully the rest of the transition can be made short enough it won't be too large of a burden. If you're somebody that runs into this kind of thing a lot, you should probably request a Mac anyway.

Brett

[Vincent Scheib]

On Tue, Apr 26, 2016 at 5:07 PM, Brett Wilson <bre...@chromium.org> wrote:

TL;DR: Please R, the details here will affect all developers.

🆕

Android and Linux are approaching GN completeness.

Very shortly, we will stop running GYP as a gclient hook for these configurations. After this happens, you can still run GYP manually if you want "python build/gyp_chromium.py" assuming it still works (see below).

In the next week, we'll finish flipping over all the bots for these configurations. As we flip configurations over to GN, the bots on the waterfall will represent the current state of GYP support. If there is a GYP bot on the waterfall, we need to support the GYP build for that configuration. If there is no GYP bot, the GYP build will be unsupported on that configuration.

How do I see "GN or GYP" for a bot when looking at https://build.chromium.org?

 

We'll remove GYP files specific to unsupported configurations as we go (they'll bitrot immediately anyway). If you are a Googler compiling the official Android build, you will be affected by this first as there are currently no official Android bots and there are a few .gyp files specific to this build.

🎵Important notes

- The GYP_DEFINES environment variable is still hooked up to control a few things in gclient like the downloading of Android libraries when OS==android. Don't assume you can delete GYP_DEFINES yet (the component flag is not used: if this is all you have it's safe to delete). Long-term, we need to figure out a better way to control these steps, but this is lower priority (please help!).

- When a configuration is unsupported, you should not feel obligated to keep GYP in sync with GN or even building. Code reviewers should not require this.

🆙 What's next

We will post updates as important classes of things become unsupported. Windows and ChromeOS will follow Android and desktop Linux. If you still use GYP for any of these platforms, you should switch to GN right away. If something doesn't work for you, we either need to know about it or you need to fix it ASAP.

Mac and iOS developers should continue using GYP for now (but not for long).

🆘 Quick start

cd mycheckout/src

gn gen out/foo  [Don't use "Debug" or "Release", you only need to do this once]

ninja -C out/foo chrome

Email gn-...@chromium.org for questions.

Thanks!

--

[Dirk Pranke]

On Fri, Apr 29, 2016 at 1:59 PM, Vincent Scheib <sch...@chromium.org> wrote:

On Tue, Apr 26, 2016 at 5:07 PM, Brett Wilson <bre...@chromium.org> wrote:

TL;DR: Please R, the details here will affect all developers.

🆕

Android and Linux are approaching GN completeness.

Very shortly, we will stop running GYP as a gclient hook for these configurations. After this happens, you can still run GYP manually if you want "python build/gyp_chromium.py" assuming it still works (see below).

In the next week, we'll finish flipping over all the bots for these configurations. As we flip configurations over to GN, the bots on the waterfall will represent the current state of GYP support. If there is a GYP bot on the waterfall, we need to support the GYP build for that configuration. If there is no GYP bot, the GYP build will be unsupported on that configuration.

How do I see "GN or GYP" for a bot when looking at https://build.chromium.org?

Good question. This is not super-easy at the moment, but

1) Look for a step called 'generate_build_files' in the most recent build log. If you don't see it, the bot is either not a builder, or one of a few exceptions, or still on GYP. The latter category shouldn't exist at this point, so if you see one, let me know.

2) Look at the log output (stdio) from the generate_build_files step, and it'll show either running GN and using GN args, or setting GYP_DEFINES and running build/gyp_chromium.

-- Dirk