Make the gn copy() tool honor dependencies.

tools/gn/ninja_copy_target_writer.cc

Index: tools/gn/ninja_copy_target_writer.cc
diff --git a/tools/gn/ninja_copy_target_writer.cc b/tools/gn/ninja_copy_target_writer.cc
index ca3485240854cd8147600fb838e36c19918df64a..6b963a7ac4f311e583f1adf9ef6c9c5f87b6d106 100644
--- a/tools/gn/ninja_copy_target_writer.cc
+++ b/tools/gn/ninja_copy_target_writer.cc
@@ -71,29 +71,35 @@ void NinjaCopyTargetWriter::WriteCopyRules(
       GetNinjaRulePrefixForToolchain(settings_) +
       Toolchain::ToolTypeToName(Toolchain::TYPE_COPY);
 
-  // Note that we don't write implicit deps for copy steps. "copy" only
-  // depends on the output files themselves, rather than having includes
-  // (the possibility of generated #includes is the main reason for implicit
+  OutputFile input_dep =
+      WriteInputDepsStampAndGetDep(std::vector<const Target*>());
+
+  // Note that we don't write implicit deps for copy steps. "copy" only depends
+  // on the output files themselves, rather than having includes (the
+  // possibility of generated #includes is the main reason for implicit
   // dependencies).
   //
   // It would seem that specifying implicit dependencies on the deps of the
-  // copy command would still be harmeless. But Chrome implements copy tools
-  // as hard links (much faster) which don't change the timestamp. If the
-  // ninja rule looks like this:
-  //   output: copy input | foo.stamp

[brettw, 2014/10/31 19:56:57]

Seems like this was auto-rewrapping that messed up the formatting? We should
keep this on its own line indented.

[Dirk Pranke, 2014/10/31 20:02:33]

Hm. I don't know what caused this, or the change on lines 101-102. Maybe I
auto-formatted something by accident. Will fix.

-  // The copy will not make a new timestamp on the output file, but the
-  // foo.stamp file generated from a previous step will have a new timestamp.
-  // The copy rule will therefore look out-of-date to Ninja and the rule will
-  // get rebuilt.
+  // copy command would still be harmeless. But Chrome implements copy tools as
+  // hard links (much faster) which don't change the timestamp. If the ninja
+  // rule looks like this: output: copy input | foo.stamp The copy will not
+  // make a new timestamp on the output file, but the foo.stamp file generated
+  // from a previous step will have a new timestamp.  The copy rule will
+  // therefore look out-of-date to Ninja and the rule will get rebuilt.
   //
   // If this copy is copying a generated file, not listing the implicit
   // dependency will be fine as long as the input to the copy is properly
   // listed as the output from the step that generated it.
   //
-  // Moreover, doing this assumes that the copy step is always a simple
-  // locally run command, so there is no need for a toolchain dependency.
-  for (size_t i = 0; i < target_->sources().size(); i++) {
-    const SourceFile& input_file = target_->sources()[i];
+  // Moreover, doing this assumes that the copy step is always a simple locally
+  // run command, so there is no need for a toolchain dependency.
+  //
+  // Note that there is the need in some cases for order-only dependencies
+  // where a command might need to make sure something else runs before it runs
+  // to avoid conflicts. Such cases should be avoided where possible, but
+  // sometimes that's not possible.
+  for (size_t i = 0; i < target_->sources().size(); i++) { const SourceFile&
+    input_file = target_->sources()[i];
 
     OutputFile output_file =
         SubstitutionWriter::ApplyPatternToSourceAsOutputFile(
@@ -104,6 +110,10 @@ void NinjaCopyTargetWriter::WriteCopyRules(
     path_output_.WriteFile(out_, output_file);
     out_ << ": " << tool_name << " ";
     path_output_.WriteFile(out_, input_file);
+    if (!input_dep.value().empty()) {
+      out_ << " || ";
+      path_output_.WriteFile(out_, input_dep);
+    }
     out_ << std::endl;
   }
 }