unexpected gn check failures

104 views
Skip to first unread message

Evan Stade

unread,
Dec 10, 2018, 6:57:59 PM12/10/18
to Chromium-dev, Dirk Pranke, Steven Bennetts
Hi all,

On a CL I'm working on[1] the mac builders are complaining at the gn args --check stage [2] for reasons I don't understand. Specifically, one example failure is:

ERROR at //chrome/browser/extensions/api/automation_internal/automation_internal_api.cc:47:11: Include not allowed. #include "ui/aura/env.h" ^------------ It is not in any dependency of //chrome/browser/extensions:extensions The include file is in the target(s): //ui/aura:aura which should somehow be reachable.

I gather I could add // nogncheck, but I didn't touch this file or any of its deps[3], so why was this passing before? Is there some rule for what directory gets gn checked which this CL is suddenly tripping?

[3] to my knowledge I only touched test-only build targets

-- Evan Stade

dan...@chromium.org

unread,
Dec 10, 2018, 7:00:49 PM12/10/18
to Evan Stade, chromium-dev, Dirk Pranke, Steven Bennetts
You changed a public_deps to a deps, which I would assume this was depending on, possibly transitively.

- Dana

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAO4XGS9X3aXsDdO8MC-3wVaTo%2B0K3wHbKTuWzWmM_OgWVLmZCQ%40mail.gmail.com.

Evan Stade

unread,
Dec 10, 2018, 8:04:20 PM12/10/18
to Dana Jansens, Chromium-dev, Dirk Pranke, Steven Bennetts
On Mon, Dec 10, 2018 at 5:00 PM <dan...@chromium.org> wrote:
You changed a public_deps to a deps, which I would assume this was depending on, possibly transitively.

- Dana

This is hypothetically possible, but the only build targets I touched the DEPS on were test targets. Unless we think it's possible that the //chrome/browser/extensions target depends on views_unittests somehow, I don't see the connection. (This also applies to //chrome/browser/ui, //content/browser, etc.)

Correct me if I'm wrong, but I don't think that anything which lacks USE_AURA /should/ be including aura files, so if it was passing the check before somehow, it must have indicated an error in the DEPS chain. Yet it's very rare that aura includes in //chrome/browser apply nogncheck (even inside USE_AURA blocks). What I can't figure out is what controls whether gn --check is being run on a directory, since the gn docs still claim that Chrome doesn't come close to passing a gn check.

Dirk Pranke

unread,
Dec 10, 2018, 8:29:13 PM12/10/18
to Evan Stade, Dana Jansens, chromium-dev, Steven Bennetts
The list of which directories are expected to pass gn check is given by the `check_targets` variable in //.gn . 

It is true that there's still a lot of work left to get everything to pass, but a greal deal of it already does.

It is not obvious to me either what's causing the failures, even after I patched the CL in locally and reproduced it. My initial look said the same thing that you're saying, which is that the changes should've only affected views_unittests. It's possible that you're hitting a bug in GN, or there's some weird interaction with circular includes going on (or both), but I didn't look very long. 

If you look into this further and still don't find an answer, please file a bug, cc me, and I'll dig into it more.

-- Dirk

Colin Blundell

unread,
Dec 11, 2018, 4:41:24 AM12/11/18
to dpr...@chromium.org, Evan Stade, Dana Jansens, chromium-dev, Steven Bennetts
I looked at this a bit as well; to perhaps state the obvious, it looks like the problem is that USE_AURA is now defined on Mac when checking the violating targets, so that the includes guarded by USE_AURA are getting analyzed. It's not surprising that that creates problems given that IIUC Mac doesn't use Aura. This would also explain why the problem is springing up everywhere, as opposed to being limited to targets that are involved in the affected dependency chain.

I don't have a Mac development environment locally at the moment, so wasn't able to dig into *why* that would be the case. Nothing in your CL springs out as causing that change.

Best,

Colin

Daniel Bratell

unread,
Dec 11, 2018, 5:40:01 AM12/11/18
to dpr...@chromium.org, Colin Blundell, Evan Stade, Dana Jansens, chromium-dev, Steven Bennetts
The include checker[1] doesn't know about conditional includes, while the BUILD.gn scripts often have conditional dependencies. That is why aura includes often have //nogncheck. 

That doesn't answer the question about why this suddenly appeared. I've seen other check errors on bots I've not seen locally but written those down to subtle configuration differences.

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGE5NEj%3D8%2BiHYOUYDL%3DouUS%2BOvNy8Q8XB2Lof23QK26ZGoWcQ%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

Evan Stade

unread,
Dec 11, 2018, 11:45:16 AM12/11/18
to bra...@opera.com, Dirk Pranke, blun...@chromium.org, Dana Jansens, Chromium-dev, Steven Bennetts
Thanks all for replies. I filed https://crbug.com/913981 to track it as I also lack a mac development environment and therefore am having a hard time debugging. (I had hoped I could at least tell gn to pretend I was on a mac, but that caused multiple errors.)

As others have noted, the mystery is as much about why gn was not already complaining before my change, as why my change would cause the new failures.

-- Evan Stade

Nico Weber

unread,
Dec 11, 2018, 2:34:07 PM12/11/18
to Evan Stade, Daniel Bratell, Dirk Pranke, Colin Blundell, Dana Jansens, Chromium-dev, Steven Bennetts
On Tue, Dec 11, 2018 at 11:43 AM Evan Stade <est...@chromium.org> wrote:
Thanks all for replies. I filed https://crbug.com/913981 to track it as I also lack a mac development environment and therefore am having a hard time debugging. (I had hoped I could at least tell gn to pretend I was on a mac, but that caused multiple errors.)

(See https://chromium-review.googlesource.com/c/chromium/src/+/1236713 for how to get past the gn stage with target_os=mac when not on a mac)
 

Evan Stade

unread,
Dec 11, 2018, 4:40:00 PM12/11/18
to Nico Weber, bra...@opera.com, Dirk Pranke, blun...@chromium.org, Dana Jansens, Chromium-dev, Steven Bennetts
On Tue, Dec 11, 2018 at 12:32 PM Nico Weber <tha...@chromium.org> wrote:
On Tue, Dec 11, 2018 at 11:43 AM Evan Stade <est...@chromium.org> wrote:
Thanks all for replies. I filed https://crbug.com/913981 to track it as I also lack a mac development environment and therefore am having a hard time debugging. (I had hoped I could at least tell gn to pretend I was on a mac, but that caused multiple errors.)

(See https://chromium-review.googlesource.com/c/chromium/src/+/1236713 for how to get past the gn stage with target_os=mac when not on a mac)

Thanks, that helps a lot. See https://bugs.chromium.org/p/chromium/issues/detail?id=913981#c1 for what I figured out.
Reply all
Reply to author
Forward
0 new messages