GYP: fix compile flake for second-hand use of generated headers.

mojo/public/tools/bindings/mojom_bindings_generator_explicit.gypi

Index: mojo/public/tools/bindings/mojom_bindings_generator_explicit.gypi
diff --git a/mojo/public/tools/bindings/mojom_bindings_generator_explicit.gypi b/mojo/public/tools/bindings/mojom_bindings_generator_explicit.gypi
index 68348fb4bc7484625ded06d2ee32f35ab8de7603..ccc1da2734683f7677b0f800c4e0287a81070a30 100644
--- a/mojo/public/tools/bindings/mojom_bindings_generator_explicit.gypi
+++ b/mojo/public/tools/bindings/mojom_bindings_generator_explicit.gypi
@@ -51,6 +51,9 @@
       '<(DEPTH)',
       '<(SHARED_INTERMEDIATE_DIR)',
     ],
+    # Make sure the generated header files are available for any static library
+    # that depends on a static library that depends on this generator.
+    'hard_dependency': 1,
     'direct_dependent_settings': {

[Nico, 2014/11/20 21:33:28]

Having a direct_dependent_settings child in a direct_depend_setting section
looks wrong to me. Either children should have to re-export stuff ( cf
https://code.google.com/p/chromium/codesearch#search/&q=export_dependent&sq=p...
) or this should be all_dependent_settings.

[jamesr, 2014/11/20 21:41:31]

all_dependent_settings seems too extreme (that means that the generator has to
run before any targets downstream can even start, even ones that have nothing to
do with the mojom.h files).  export_dependent_settings should work for this but
I got piles of duplicate symbol errors in various content/ targets no matter
what I tried.

[Nico, 2014/11/20 21:45:14]

Try harder? As is, this works fine for 2 levels of deps and then fails silently,
with brokenness like in the linked bug.

[Nick Bray (chromium), 2014/11/20 21:48:55]

all_dependent_settings was deemed too extreme on code review.
I was unaware of export_dependent_settings.  I don't think it would work because
we only want to inject the sources and hard_dependency one level deep, but the
include directories two levels deep.
I don't think it's particularly pretty, but I don't see a better way to do this
without being explicit and redundant on a non-trivial number of targets. 
Thoughts?


Also, I am explicitly _not_ supporting n-th level transitive dependencies.  If
you use header files for the library, you must explicitly depend on the library.
 But this has always been the case for mojo's libraries.

       # Include paths needed to find the generated header files and their
       # transitive dependancies when using the library.
@@ -65,5 +68,4 @@
       },
     }
   },
-  'hard_dependency': 1,

[Nico, 2014/11/20 21:33:28]

Don't you need both this too?

[Nick Bray (chromium), 2014/11/20 21:48:55]

I believe hard_dependency only affects dependencies between libraries.  This
line would set the flag on an action.  Ninja produces the same output with and
without this line.  It appears to have no effect, at least for the Ninja
generator.  I could leave it in with heady commenting if there is a possibility
other generators might behave differently.

 }