fix third_party_headers to work properly on Windows w/ ninja.

webkit/support/setup_third_party.gyp

Index: webkit/support/setup_third_party.gyp
diff --git a/webkit/support/setup_third_party.gyp b/webkit/support/setup_third_party.gyp
index 7fc15ac9647091def3335e3c35ee6f50282a7c0f..7e776d6e7c1d234923a9cb4844c52847af9f66e1 100644
--- a/webkit/support/setup_third_party.gyp
+++ b/webkit/support/setup_third_party.gyp
@@ -11,6 +11,19 @@
   },
   'targets': [
     {
+      # This target is only invoked when we are building chromium inside
+      # of a WebKit checkout. In this case, we will have chromium files
+      # that include WebKit headers via third_party/WebKit/Source/... ;
+      # that directory doesn't exist in a chromium-inside-webkit
+      # checkout, and so we need to create sets of forwarding headers.
+      #
+      # In addition, we can hit limits on the include paths on windows
+      # with a regular forwarding header due to the deep directory
+      # hierarchies, and so rather than using #includes that are relative
+      # to the directory containing the generated header, the generated files
+      # use #includes that are relative to <(DEPTH), which is assumed to
+      # already (and always) be in the include_dir path

[Dirk Pranke, 2013/02/09 03:35:12]

Let me know if you think this comment is too verbose. In addition, I waffled on
whether to add '<(DEPTH)' to include_dirs to ensure that this would always be
right, but I wasn't sure if we can safely assume that '<(DEPTH)' will always be
in the include_dirs path, or if gyp would be smart enough to remove duplicate
entries from include_dirs.

Thoughts?

[Ryan Sleevi, 2013/02/10 11:06:01]

GYP doesn't ensure this. You would have to manually specify it. I'm also not
sure how well that would work if you were trying to have it propagate to
dependencies (since the <(DEPTH) will be relative to the GYP file, as would
'..'). It may work via late expansion, though.
It's supposed to - see
https://code.google.com/p/gyp/wiki/InputFormatReference#List_Singletons

[tony, 2013/02/11 18:16:50]

It sounds like we should have a direct_dependant_settings to add <(DEPTH) to
includes?

[Ryan Sleevi, 2013/02/11 18:19:18]

<(DEPTH) won't be absolutized, so it would result in something like '-I../..',
which will work if you're in src/foo/bar/bar.gyp, but do nothing if you're in
src/baz/bat/frob/frob.gyp

That is, I don't think it'll do what you expect.

[tony, 2013/02/11 20:05:38]

I see.  It sounds like we should just hardcode '../..' which will be the 'src'
directory.

[Dirk Pranke, 2013/02/11 23:42:30]

Someone's confused. Maybe it's me :) Assuming we add this to include_dirs,
doesn't that get relativized as well as treated as a singleton? In otherwords, I
think it will / does?

[Ryan Sleevi, 2013/02/11 23:50:10]

It's me. I'm the confused one. Ignore me.

+
       'target_name': 'third_party_headers',
       'type': 'none',
       'direct_dependent_settings': {
@@ -33,6 +46,7 @@
             'setup_headers',
             '<(DEPTH)/public',
             '<(webkit_client_api_dest)',
+            '<(DEPTH)',
           ],
           'message': 'Generating forwarding headers for third_party/WebKit/Source/WebKit/chromium/public',
         },
@@ -72,6 +86,7 @@
                 'setup_headers',
                 '<(DEPTH)/../mac/WebCoreSupport',
                 '<(mac_webcoresupport_dest)',
+                '<(DEPTH)',
               ],
               'message': 'Generating forwarding headers for third_party/WebKit/Source/WebKit/mac/WebCoreSupport',
             },