Update MB for the new way to run 'analyze'.

tools/mb/docs/design_spec.md

 # The MB (Meta-Build wrapper) design spec
 
 [TOC]
 
 ## Intro
 
 MB is intended to address two major aspects of the GYP -> GN transition
 for Chromium:
 
 1. "bot toggling" - make it so that we can easily flip a given bot
@@ skipping 169 matching lines @@
 graph at all). We can't tell these two apart, so we should ignore missing
 files.
 
 There may be targets listed in the input that don't exist in the build
 graph; unlike missing files, this can only indicate a configuration error,
 and so we should return which targets are missing so the caller can
 treat this as an error, if so desired.
 
 Any of the three inputs may be an empty list:
 
-* It doesn't make sense to call analyze at all if no files were modified,
-  so this should probably return an error.
+* It normally doesn't make sense to call analyze at all if no files
+  were modified, but in rare cases we can hit a race where we try to
+  test a patch after it has already been committed, in which case
+  the list of modified files is empty. We should return 'no dependency'
+  in that case.

[Dirk Pranke, 2015/11/13 02:14:28]

sky@, you might want to double-check that GYP handles this properly as well.

[sky, 2015/11/13 16:26:49]

GYP ends up generating an error in this case. I don't know how the recipe side
handles that error.

 
 * Passing an empty list for one or the other of test_targets and
   additional_compile_targets is perfectly sensible: in the former case,
   it can indicate that you don't want to run any tests, and in the latter,
   it can indicate that you don't want to do build anything else in
   addition to the test targets.
 
 * It doesn't make sense to call analyze if you don't want to compile
   anything at all, so passing [] for both test_targets and 
   additional_compile_targets should probably return an error.
@@ skipping 216 matching lines @@
 * Some common flags (goma\_dir being the obvious one) may need to be
   specified via the user, and it's unclear how to integrate this with
   the concept of build\_configs.
 
   Right now, MB has hard-coded support for a few flags (i.e., you can
   pass the --goma-dir flag, and it will know to expand "${goma\_dir}" in
   the string before calling out to the tool. We may want to generalize
   this to a common key/value approach (perhaps then meeting the
   ChromeOS non-goal, above), or we may want to keep this very strictly
   limited for simplicity.