[MD History] Vulcanize as part of GN build.

chrome/browser/resources/md_history/BUILD.gn

+import("../vulcanize.gni")
+
+vulcanize("vulcanize_app") {
+  host = "history"
+  html_in_file = "app.html"
+  html_out_file = "app.vulcanized.html.unbuilt"
+
+  input_type = "FOLDER"
+  input = rebase_path(".", root_build_dir)
+  js_out_file = "app.crisper.js"
+
+  excludes = [
+    "chrome://resources/html/util.html",
+    "chrome://history/constants.html",
+  ]
+
+  deps = []
+}
+
+vulcanize("vulcanize_lazy_load") {
+  host = "history"
+  html_in_file = "lazy_load.html"
+  html_out_file = "lazy_load.vulcanized.html.unbuilt"
+
+  input_type = "FOLDER"
+  input = rebase_path(".", root_build_dir)
+  js_out_file = "lazy_load.crisper.js"
+  excludes = [ "chrome://history/app.html" ]
+
+  deps = []
+}
+
+css_build("build") {

[dpapad, 2017/02/02 22:08:45]

I am trying to understand the necessity of splitting css_build to its own
action. At first glance, I don't see why is necessary (and I think it makes the
build files more complicated).

Why can't we have the vulcanize() rule run polymer_css_build, on the
html_out_file. We are removing that as part of vulcanize, and then we invoke it
separately, just to pass the 2 previously created html_out_file(s) together.

Per my understanding if each vulcanize() invocation produces a fully processed
output file, there is no need to do anything separately. There will be one rule
for each of vulcanize_app and vulcanize_lazy_load, and each of the outputs will
have already been processed by polymer_css_build.

+  input_files = [
+    "lazy_load.vulcanized.html.unbuilt",
+    "app.vulcanized.html.unbuilt",
+  ]
+  output_files = [
+    "lazy_load.vulcanized.html",
+    "app.vulcanized.html",
+  ]
+  deps = [
+    ":vulcanize_app",
+    ":vulcanize_lazy_load",
+  ]
+}