Mark kasko as a hard dependency since it depends on kasko_features which generates a header file.

third_party/kasko/kasko.gyp

 {
   'targets': [
     {
       # GN: //third_party/kasko:kasko_features
       'target_name': 'kasko_features',
       'type': 'none',
       'includes': [ '../../build/buildflag_header.gypi' ],
       'variables': {
         'buildflag_header_path': 'third_party/kasko/kasko_features.h',
         'buildflag_flags': [
@@ skipping 25 matching lines @@
                 '<(kasko_exe_dir)/kasko.dll',
                 '<(kasko_exe_dir)/kasko.dll.pdb',
               ],
             },
           ],
         },
         {
           # GN: //third_party/kasko
           'target_name': 'kasko',
           'type': 'none',
+          'hard_dependency': 1,

[blundell, 2016/05/17 08:16:38]

I don't think that this will fix the problem because lines 66-68 already export
the fact that kasko_features is a hard dependency, so the problem is somewhere
else in the dependency chain.

I think that the crash_component target should depend directly on kasko_features
and do export_dependent_settings on it, since it includes kasko_features.h
directly in crashpad.h. I'm not sure that our (meta)-build systems make any
guarantees when there are missing dependencies in the dependency graph (e.g.,
the fact that crash_component depends directly on kasko_features).

As a sanity check, I assume that you're sure that the failing builds are GYP and
not GN builds?

           'dependencies': [
             'copy_kasko_dll',
             'kasko_features',
           ],
           'direct_dependent_settings': {
             'msvs_settings': {
               'VCLinkerTool': {
                 'AdditionalDependencies': [
                   'kasko.dll.lib',
                 ],
@@ skipping 18 matching lines @@
           'target_name': 'kasko',
           'type': 'none',
           'dependencies': [
             'kasko_features',
           ],
         },
       ],
     }],
   ],  # 'conditions'
 }