Make changes to mini_installer test files trigger tests.

chrome/installer/mini_installer.gyp

Index: chrome/installer/mini_installer.gyp
diff --git a/chrome/installer/mini_installer.gyp b/chrome/installer/mini_installer.gyp
index 45d82a3bbbf2ab6e4167a384b77bfb28c5f51497..aeab18957349f8cdf5a5691ea850b27e96230332 100644
--- a/chrome/installer/mini_installer.gyp
+++ b/chrome/installer/mini_installer.gyp
@@ -16,6 +16,27 @@
     ['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',
 
@@ -25,6 +46,7 @@
             '../chrome.gyp:chrome_dll',
             '../chrome.gyp:default_extensions',
             '../chrome.gyp:setup',
+            'test_installer_sentinel',
           ],
           'include_dirs': [
             '../..',