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

mojo/public/tools/bindings/mojom_bindings_generator_explicit.gypi

 # Copyright 2013 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 {
   'includes': [
     'mojom_bindings_generator_variables.gypi',
   ],
   'variables': {
     'mojom_base_output_dir':
@@ skipping 33 matching lines @@
   ],
   'direct_dependent_settings': {
     'sources': [
       '<@(mojom_generated_outputs)',
     ],
     # Include paths needed to compile the generated sources into a library.
     'include_dirs': [
       '<(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.
       'include_dirs': [
         '<(DEPTH)',
         '<(SHARED_INTERMEDIATE_DIR)',
       ],
       'variables': {
         'generated_src_dirs': [
           '<(PRODUCT_DIR)/java_mojo/<(_target_name)/src',
         ],
       },
     }
   },
-  '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.

 }