Fix //content/plugin ax_enums gn build flake (take 2)

Fix //content/plugin ax_enums gn build flake (take 2)

Flake observerd with target_os="android" and enable_plugins=true,
probably can happen on other platforms as well.
//content/plugin/plugin_thread.cc ends up including the generated
ax_enums header so needs a dependency.

This is a retry of crrev.com/1343883003 with a direct ax_gen dep instead
of going via //content/public/common to avoid a dependency cycle in
component builds.

R=ananta@chromium.org, jam@chromium.org
BUG=

Committed: https://crrev.com/d09fa1676fb063d617bde289f552108ac17d1cde
Cr-Commit-Position: refs/heads/master@{#349228}

[tsniatowski, 2015-09-15 18:17:27]

PTAL -- now shouldn't break component build
previous CL: crrev.com/1343883003

[jam, 2015-09-15 22:09:21]

lgtm

[jam, 2015-09-15 22:11:31]

On 2015/09/15 22:09:21, jam wrote:
> lgtm

actually, not lgtm. content/plugin should depend on content/common. it shouldn't
have to know what content/common depends on

[jam, 2015-09-15 22:11:44]

jam@chromium.org changed reviewers:
+ brettw@chromium.org

[jam, 2015-09-15 22:11:44]

+brett for his thoughts

[brettw, 2015-09-15 23:59:42]

John is, a target should depend on the deps for the headers it uses. If those
headers in turn rely on other stuff, those should be public deps of the
intermediate target to form a chain.

If you're not sure what to do, if you can list the include chain that gives the
problem (I looked briefly and one wasn't immediately obvious) I can advise.

[brettw, 2015-09-16 03:20:34]

On 2015/09/15 23:59:42, brettw wrote:
> John is, a 

-> John is right, a...

[tsniatowski, 2015-09-16 05:20:18]

On 2015/09/15 23:59:42, brettw wrote:
> John is, a target should depend on the deps for the headers it uses. If those
> headers in turn rely on other stuff, those should be public deps of the
> intermediate target to form a chain.
> 
> If you're not sure what to do, if you can list the include chain that gives
the
> problem (I looked briefly and one wasn't immediately obvious) I can advise.

The include chain is:
In file included from
../content/public/common/common_param_traits_macros.h:25:0,
                 from ../content/public/common/common_param_traits.h:21,
                 from ../content/common/plugin_process_messages.h:10,
                 from ../content/plugin/plugin_thread.cc:25:
../ui/accessibility/ax_node_data.h:14:39: fatal error:
ui/accessibility/ax_enums.h: No such file or directory
 #include "ui/accessibility/ax_enums.h"

Reproduction usually requires a "gn clean" since compiler depfiles make the
dependency be correct in incremental builds.

On 2015/09/15 22:11:31, jam wrote:
> actually, not lgtm. content/plugin should depend on content/common. it
shouldn't
> have to know what content/common depends on

Making //content/plugin depend on //content/common trips a visibility check:
ERROR at //content/plugin/BUILD.gn:9:3: Dependency not allowed.
  source_set("plugin") {
  ^---------------------
The item //content/plugin:plugin
can not depend on //content/common:common
because it is not in //content/common:common's visibility list: [
  //content/public/common:common_sources
]

Making //content/plugin depend on //content/public/common works in a default
build, but ends up creating a dependency cycle in a component build:
ERROR Dependency cycle:
  //content:content ->
  //content/public/plugin:plugin_sources ->
  //content/plugin:plugin ->
  //content/public/common:common ->
  //content:content.

I'm not sure what to do at this point, hints appreciated.

[brettw, 2015-09-16 16:58:26]

It looks like you should depend on "//content/public/common:common_sources".
This content thing is delicate to get the component build and non-component
build the way we want while also preventing cycles. It looks like renderer and
utility both already depend on this.

[tsniatowski, 2015-09-16 18:31:10]

On 2015/09/16 16:58:26, brettw wrote:
> It looks like you should depend on "//content/public/common:common_sources".
> This content thing is delicate to get the component build and non-component
> build the way we want while also preventing cycles. It looks like renderer and
> utility both already depend on this.

This seems to work in both cases; ninja -t commands shows ax_gen happens on a
fresh gn gen dir before content/plugin sources are compiled. Thanks, and PTAL.

[jam, 2015-09-16 20:05:21]

lgtm

thanks folks

[tsniatowski, 2015-09-16 20:19:48]

The CQ bit was checked by tsniatowski@opera.com

[commit-bot: I haz the power, 2015-09-16 20:21:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1344883002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1344883002/20001

[commit-bot: I haz the power, 2015-09-16 20:58:33]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-09-16 20:59:14]

Patchset 2 (id:??) landed as
https://crrev.com/d09fa1676fb063d617bde289f552108ac17d1cde
Cr-Commit-Position: refs/heads/master@{#349228}