New build flag system, convert Google Now flag

build/build_header.gypi

Index: build/build_header.gypi
diff --git a/build/build_header.gypi b/build/build_header.gypi
new file mode 100644
index 0000000000000000000000000000000000000000..1611e13cae0a4ed611e1c2c34af5c10c07923d61
--- /dev/null
+++ b/build/build_header.gypi
@@ -0,0 +1,116 @@
+# Copyright 2015 The Chromium Authors. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+# Generates a header with preprocessor defines specified by the build file.
+#
+# The canonical documentation is in build/build_header.gni. You should write
+# the GN build, get it working, and then transform it into GYP.
+#
+# IN EVERY TARGET THAT USES YOUR GENERATED HEADER you must include a dependency

[Mark Mentovai, 2015/11/19 21:52:55]

WHY ARE YOU YELLING AT ME?

[brettw, 2015/11/20 00:02:37]

Done.

+# on the GYP target that generates the header (this is implicit in GN).
+# Otherwise, clean builds may not necessarily create the header before the
+# source code is compiled.
+#
+# Assuming your GN code looks like this:

[Mark Mentovai, 2015/11/19 21:52:55]

It’d be helpful if this matched the GN example exactly, with the space laser and
all.

[brettw, 2015/11/20 00:02:37]

But GYP doesn't support the space laser!

+#
+#   build_header("foo_features") {
+#     header = "foo_features.h"
+#     flags = [ "ENABLE_DOOM_MELON=$enable_doom_melon" ]
+#     variables = [ "MY_URL=\"http://www.example.com/" ]

[Mark Mentovai, 2015/11/19 21:52:55]

\" as before. You got this right in the GYP example.

[brettw, 2015/11/20 00:02:37]

Done.

+#   }
+#
+# Write a GYP target like this:

[Mark Mentovai, 2015/11/19 21:52:55]

It’d be useful to know that you’re expecting to see this in foo/bar/foobar.gyp
or whatever.

[brettw, 2015/11/20 00:02:37]

I renamed the target too foo_features. I left out the file it should go in. The
files between GYP and GN are often quite different (GN has lots more little
ones). I this people will be able to find the most appropriate file for
foo-related stuff to put the foo header target in.

+#
+#  {
+#    # GN version: //foo/bar:foo_features
+#    'target_name': 'foo_bar_foo_features',
+#    'includes': [ '../build/build_header.gypi' ],
+#    'variables': {
+#       'build_header_path': 'foo/bar/foo_features.h',

[Mark Mentovai, 2015/11/19 21:52:55]

You’d be more likely to find bar_featues.h or foobar_features.h at this path.

[brettw, 2015/11/20 00:02:37]

Renamed to just foo/foo_features.h

+#       'build_header_flags': [ 'ENABLE_DOOM_MELON=<(enable_doom_melon)' ],
+#       'build_header_variables': [ 'MY_URL="http://www.example.com/"' ],
+#     },
+#   }
+#
+# Variables
+#
+#   target_name
+#       Base this on the GN label, replacing / and : with _ to make it globally
+#       unique.
+#
+#   build_header_path
+#       This must be the full path to the header from the source root. In GN
+#       you only say "features.h" and it uses the BUILD file's path implicitly.
+#       Use the path to BUILD.gn followed by your header name to produce the
+#       same output file.
+#
+#   build_header_flags (optional)
+#       List of the same format as GN's "flags". To expand variables, use
+#       "<(foo)" where GN would have used "$foo".
+#
+#   build_header_variables (optional)
+#       List of the same format as GN's "variables".
+#
+#   includes
+#       List the relative path to build/build_header.gypi from the .gyp file
+#       including this code, Note: If your code is in a .gypi file in a
+#       different directory, this must be relative to the .gyp including your
+#       file.
+#
+#
+# Grit defines
+#
+# Follow the same advice as in the build_header.gni, except on the grit action
+# use the variable name 'grit_additional_defines' and explicitly add a '-D' in
+# front:
+#
+#   'grit_grd_file': 'foo.grd',
+#   'grit_additional_defines': [
+#     '-D', 'enable_doom_melon=<(enable_doom_melon)',
+#    ],
+#
+# Put shared lists of defines in a .gypi.
+
+{
+  'type': 'none',

[Mark Mentovai, 2015/11/19 21:52:55]

Why do this in a separate target? If you write this so that can be included by
the target that wants to generate the header, the including target can be
responsible for generating its header itself, without the need to express any
extra dependencies. It can decide to not be hard if its header is private to the
target, for example. If some consumer does want these semantics, then they can
write things exactly as you’ve got here, with the addition of having a local
'type': 'none', 'hard_dependency': 1.

Since one motivator here is to keep private flags isolated to the target or
targets that need them, I suspect that many flags that are used in a small
number of places actually are all isolated to a single target, where it’s fine
to just run the action right in the target itself and not try to expose it to
dependents.

[brettw, 2015/11/20 00:02:37]

I considered the action thing but I did this on purpose.

I was going for their being as close to a 1:1 correspondence between GYP and GN
here, and in GN all actions are targets. I want to be able to automatically
force the target to be a hard dependency, and I want people to have to add
dependencies in the same way. Since this is a generated file, it means marking
the target as a hard dependency, which is not good in general for many typical
places this would hang off of (like chrome_common or whatever).

My main worry is that people will forget to add dependencies so that the header
isn't generated in time. I think having a separate target with a name that
matches GN will help with this.

+  'hard_dependency': 1,
+
+  'actions': [
+    {
+      'action_name': 'build_header',
+      'variables': {
+        # Default these values to empty if they're not defined.
+        'variables': {
+          'build_header_flags%': [],
+          'build_header_variables%': [],
+        },
+
+        # Writes the flags and variables to a response file with a name based
+        # on the name of this target.

[Mark Mentovai, 2015/11/19 21:52:55]

Where does this file live? Hopefully not in the source tree.

[brettw, 2015/11/20 00:02:37]

I spent a long time on this. This <| thing seems to write it into out/gypfiles,
and it will break if you specify a path. This was confusing to me but it sort of
makes sense since it will be referenced from both out/Debug and out/Release so
can't live in either.

I didn't comment this since it's just a built-in GYP thing that's not commented
in any of the other places this feature is used.

+        'response_file_name': '<|(<(_target_name)_build_header.rsp --flags <@(build_header_flags) --variables <@(build_header_variables))',
+
+        'build_header_script': '<(DEPTH)/build/write_build_header.py',
+        'relative_header_path': '<(SHARED_INTERMEDIATE_DIR)/<(build_header_path)',
+      },
+
+      'message': 'Generating build header.',
+
+      'inputs': [
+        '<(build_header_script)',
+        '<(response_file_name)',
+      ],
+
+      'outputs': [
+        '<(relative_header_path)',
+      ],
+
+      'action': [
+        'python', '<(build_header_script)',
+        '--output', '<(relative_header_path)',
+        '--path-for-guard', '<(build_header_path)',
+        '--definitions', '<(response_file_name)',
+      ],
+    }
+  ],
+}