Rewrite relative includes in public/web/

Rewrite relative includes in public/web/

Leave the few that broke compilation in Chromium if fixed.

BUG=none

[abarth-chromium, 2013-11-07 23:32:09]

lgtm

Thanks!

[commit-bot: I haz the power, 2013-11-07 23:32:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/philipj@opera.com/65763002/30001

[commit-bot: I haz the power, 2013-11-08 00:29:34]

Sorry for I got bad news for ya.
Compile failed with a clobber build on win_blink_rel.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_blink_...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[philipj_slow, 2013-11-08 20:06:00]

Adam, I had to revert more and more to make this compile, and I still haven't
pleased win_blink_rel. Do you know what's going on here? Are some parts of
Chromium compiled with third_party/WebKit on the include path but others not?
Surely being completely inconsistent about when to use relative include paths
isn't the correct fix, so what is?

[abarth-chromium, 2013-11-08 20:54:15]

On 2013/11/08 20:06:00, philipj wrote:
> Adam, I had to revert more and more to make this compile, and I still haven't
> pleased win_blink_rel. Do you know what's going on here? Are some parts of
> Chromium compiled with third_party/WebKit on the include path but others not?
> Surely being completely inconsistent about when to use relative include paths
> isn't the correct fix, so what is?

Yeah.  We probably need to add an empty "configuration" target somewhere in
public/*.gyp so that code that includes these headers can get the proper include
paths.  We can also hold off on these cases until we move to src/blink.  Then we
won't have these problems because we'll use include paths from src like everyone
else in Chromium.

[philipj_slow, 2013-11-08 20:58:59]

On 2013/11/08 20:54:15, abarth wrote:
> On 2013/11/08 20:06:00, philipj wrote:
> > Adam, I had to revert more and more to make this compile, and I still
haven't
> > pleased win_blink_rel. Do you know what's going on here? Are some parts of
> > Chromium compiled with third_party/WebKit on the include path but others
not?
> > Surely being completely inconsistent about when to use relative include
paths
> > isn't the correct fix, so what is?
> 
> Yeah.  We probably need to add an empty "configuration" target somewhere in
> public/*.gyp so that code that includes these headers can get the proper
include
> paths.  We can also hold off on these cases until we move to src/blink.  Then
we
> won't have these problems because we'll use include paths from src like
everyone
> else in Chromium.

To be clear, would you like me to keep trying until I've convinced win_blink_rel
to compile, or should I just drop this whole review?

[jamesr, 2013-11-08 21:05:20]

On 2013/11/08 20:58:59, philipj wrote:
> On 2013/11/08 20:54:15, abarth wrote:
> > On 2013/11/08 20:06:00, philipj wrote:
> > > Adam, I had to revert more and more to make this compile, and I still
> haven't
> > > pleased win_blink_rel. Do you know what's going on here? Are some parts of
> > > Chromium compiled with third_party/WebKit on the include path but others
> not?
> > > Surely being completely inconsistent about when to use relative include
> paths
> > > isn't the correct fix, so what is?
> > 
> > Yeah.  We probably need to add an empty "configuration" target somewhere in
> > public/*.gyp so that code that includes these headers can get the proper
> include
> > paths.  We can also hold off on these cases until we move to src/blink. 
Then
> we
> > won't have these problems because we'll use include paths from src like
> everyone
> > else in Chromium.
> 
> To be clear, would you like me to keep trying until I've convinced
win_blink_rel
> to compile, or should I just drop this whole review?

The issue here appears to be that targets in Chromium are using the blink API
headers without declaring a dependency in GYP on the blink target.  This is a
logical dependency bug.  I recall that someone hit this recently with
content_browsertests because on windows content_browser has no dependencies on
Blink, but the test targets use things anyway.  We should fix the dependencies
on the chromium side.  I don't think the move to src/blink will really help us
until we convert all #includes to be absolute.

I can't tell from the compile error which .cc file is trying to #include
WebConsoleMessage.h.  If you can find it, it'd be helpful to fix the
underspecified dependency.

[philipj_slow, 2013-11-09 22:11:53]

On 2013/11/08 21:05:20, jamesr wrote:
> On 2013/11/08 20:58:59, philipj wrote:
> > On 2013/11/08 20:54:15, abarth wrote:
> > > On 2013/11/08 20:06:00, philipj wrote:
> > > > Adam, I had to revert more and more to make this compile, and I still
> > haven't
> > > > pleased win_blink_rel. Do you know what's going on here? Are some parts
of
> > > > Chromium compiled with third_party/WebKit on the include path but others
> > not?
> > > > Surely being completely inconsistent about when to use relative include
> > paths
> > > > isn't the correct fix, so what is?
> > > 
> > > Yeah.  We probably need to add an empty "configuration" target somewhere
in
> > > public/*.gyp so that code that includes these headers can get the proper
> > include
> > > paths.  We can also hold off on these cases until we move to src/blink. 
> Then
> > we
> > > won't have these problems because we'll use include paths from src like
> > everyone
> > > else in Chromium.
> > 
> > To be clear, would you like me to keep trying until I've convinced
> win_blink_rel
> > to compile, or should I just drop this whole review?
> 
> The issue here appears to be that targets in Chromium are using the blink API
> headers without declaring a dependency in GYP on the blink target.  This is a
> logical dependency bug.  I recall that someone hit this recently with
> content_browsertests because on windows content_browser has no dependencies on
> Blink, but the test targets use things anyway.  We should fix the dependencies
> on the chromium side.  I don't think the move to src/blink will really help us
> until we convert all #includes to be absolute.
> 
> I can't tell from the compile error which .cc file is trying to #include
> WebConsoleMessage.h.  If you can find it, it'd be helpful to fix the
> underspecified dependency.

Thanks James, I was able to find and fix those that cause compilation to fail
locally: https://codereview.chromium.org/59683003/

I think there are likely more missing dependencies, but without a Windows
machine to build on, I think I'll have to resort to sending one patch to
Chromium, waiting for it to land, and then retrying this review, until hopefully
it works.

[abarth-chromium, 2013-11-11 18:53:12]

That sounds slow and no fun.  We can tackle this problem another day if you're
not enjoying working on it.

[philipj_slow, 2013-11-12 08:16:49]

On 2013/11/11 18:53:12, abarth wrote:
> That sounds slow and no fun.  We can tackle this problem another day if you're
> not enjoying working on it.

Yeah, this is was a pretty terrible way of fixing compile errors. Maybe I'll
give it another go after rewriting include paths for headers that have been
moved from web/ to platform/, which should remove many of the cases which were
problematic here. Closing.