New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 659512 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Nov 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocking:
issue 632008



Sign in to add a comment

gn gen fails on linux_chromium_headless_rel.gn

Project Member Reported by perezju@chromium.org, Oct 26 2016

Issue description

This is causing failures on analyze step of
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_headless_rel

What steps will reproduce the problem?
(1) echo "gn" > out/Release/mb_type
(2) echo 'import("//build/args/bots/tryserver.chromium.linux/linux_chromium_headless_rel.gn")' > out/Release/args.gn
(3) gn gen //out/Release --check

What is the expected output?

Done. Made 5067 targets from 1120 files in 2721ms

What do you see instead?

ERROR at //content/public/test/content_test_suite_base.cc:27:11: Can't include this header from here.
#include "gin/v8_initializer.h"
          ^-------------------
The target:
  //content/test:test_support
is including a file from the target:
  //gin:gin

It's usually best to depend directly on the destination target.
In some cases, the destination target is considered a subcomponent
of an intermediate target. In this case, the intermediate target
should depend publicly on the destination to forward the ability
to include headers.

Dependency chain (there may also be others):
  //content/test:test_support -->
  //ppapi/proxy:proxy --[private]-->
  //gin:gin

___________________
ERROR at //content/test/test_blink_web_unit_test_support.cc:47:11: Can't include this header from here.
#include "gin/v8_initializer.h"
          ^-------------------
The target:
  //content/test:test_support
is including a file from the target:
  //gin:gin

It's usually best to depend directly on the destination target.
In some cases, the destination target is considered a subcomponent
of an intermediate target. In this case, the intermediate target
should depend publicly on the destination to forward the ability
to include headers.

Dependency chain (there may also be others):
  //content/test:test_support -->
  //ppapi/proxy:proxy --[private]-->
  //gin:gin

~~~~

Also switching: is_debug = false ==> true in the linux_chromium_headless_rel.gn causes the error to go away.

Any ideas of what could be going wrong?
 
Blocking: 632008
Cc: alexclarke@chromium.org
Sami, Alex, any clues on how to debug this? Not really sure how these gn configs should work.
I know we need import("//build/args/headless.gn") but apart from that it's a vanilla config.
Weird. Looks like this is somehow related to component builds. Setting   is_component_build = false makes things work. Would that be a reasonable config for the bot?
Hmm, somehow I got it working the other way around, namely:

import("//build/args/headless.gn")
is_debug = false
is_component_build = true
dcheck_always_on = true
use_goma = true
symbol_level = 1

~~~

With is_component_build = false then it doesn't work, regardless of the value for is_debug. Or am I doing something wrong?

Will start preparing a CL anyway.
It's `gn gen --check` that's failing, so looking for documentation on GN check is a good way to debug what's wrong :).

In this case, you're hitting 

https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/reference.md#nogncheck_Skip-an-include-line-from-checking

The problem is that gin/v8_initializer.h is conditionally guarded by V8_USE_EXTERNAL_STARTUP_DATA. In nearly all configurations, that is defined and the correct dependency is added to //content/test:test_support (via //v8 and //v8:maybe_v8_snapshot), but headless is special since it sets v8_use_external_startup_data=false. 

When that happens, the GN dependency is (correctly) *not* added, and the file isn't included, but as the GN docs say, GN's checker isn't smart enough to figure that out.

So, the fix is to add "// nogncheck" to //content/test/test_blink_web_unit_test_support.cc:27 .
Sorry for the delays! Hopefully the trybot should be working again now.

Sami, Alex, could you give it a try?
Thanks! Kicked off a job here: https://codereview.chromium.org/2473073003/
Status: Fixed (was: Untriaged)
Looks like the build failed, but this time with reasons unrelated to its setup, i.e., everything seems to be working. Thanks again!

Sign in to add a comment