Make changes to mini_installer test files trigger tests.

chrome/installer/mini_installer.gyp

 {
   'variables': {
     'version_py': '<(DEPTH)/build/util/version.py',
     'version_path': '../../chrome/VERSION',
     'lastchange_path': '<(DEPTH)/build/util/LASTCHANGE',
     # 'branding_dir' is set in the 'conditions' section at the bottom.
     'msvs_use_common_release': 0,
     'msvs_use_common_linker_extras': 0,
     'mini_installer_internal_deps%': 0,
     'mini_installer_official_deps%': 0,
   },
   'includes': [
     '../../build/win_precompile.gypi',
   ],
   'conditions': [
     ['OS=="win"', {
       'targets': [
         {
+          # A target that is outdated if any of the mini_installer test sources
+          # are modified.
+          'target_name': 'test_installer_sentinel',
+          'type': 'none',
+          'actions': [
+            {
+              'action_name': 'touch_sentinel',
+              'variables': {
+                'touch_sentinel_py': '../tools/build/win/touch_sentinel.py',
+              },
+              'inputs': [
+                '<(touch_sentinel_py)',
+                '../tools/build/list_test_installer_sources.py',
+                '<!@pymod_do_main(list_test_installer_sources ../test/mini_installer)',

[brettw, 2015/02/23 18:25:21]

I don't think we should be doing filesystem operations in the middle of the
metabuild step. This brings the whole metabuild operation to a halt while some
Python code goes and paws around the disk.

While the GYP runtimes are such a disaster that it won't matter, there's
something to be said for not making it worse. And this type of thing makes a
really big difference in runtime in GN where the metabuild performance problems
are fixed. I've gone through some effort to remove these kind of thing in the GN
build.

If this code seldom changes, I think it's OK to just list the files manually,
and maybe add a README to the directory(s) in question for people that happen to
be adding new files to not forget to update the list.

If this is more frequently changing or you're more paranoid, what I've done is
list the files but then write an action that runs at build time that enumerates
the files and then compares them to the hardcoded list. This action would
produce a stamp file on success, or fail if the lists don't match.

This approach has the advantage that you're spending time during the slow build
step, and then only for people compiling mini installer, rather than taking time
every time any engineer syncs or updates a build file.

+              ],
+              'outputs': ['<(SHARED_INTERMEDIATE_DIR)/chrome/installer/test_installer_sentinel'],
+              'action': ['python', '<(touch_sentinel_py)', '<@(_outputs)'],
+            },
+          ],
+        },
+        {
           'target_name': 'mini_installer',
           'type': 'executable',
 
           'dependencies': [
             '../chrome.gyp:chrome',
             '../chrome.gyp:chrome_nacl_win64',
             '../chrome.gyp:chrome_dll',
             '../chrome.gyp:default_extensions',
             '../chrome.gyp:setup',
+            'test_installer_sentinel',
           ],
           'include_dirs': [
             '../..',
             '<(INTERMEDIATE_DIR)',
             '<(SHARED_INTERMEDIATE_DIR)/chrome',
           ],
           'sources': [
             '<(INTERMEDIATE_DIR)/packed_files.rc',
             'mini_installer/appid.h',
             'mini_installer/chrome.release',
@@ skipping 279 matching lines @@
       'variables': {
          'branding_dir': '../app/theme/google_chrome',
       },
     }, { # else branding!="Chrome"
       'variables': {
          'branding_dir': '../app/theme/chromium',
       },
     }],
   ],
 }