Code generation for extensions api

build/json_schema_compile.gypi

+# Copyright (c) 2011 The Chromium Authors. All rights reserved.

[Aaron Boodman, 2012/01/19 23:31:13]

I know next to nothing about gyp, so I'm going to ignore this. Nico seems like
he's on top of it.

+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+{
+  'variables': {
+    'api_gen_dir': '<(DEPTH)/tools/json_schema_compiler',
+    'api_gen': '<(api_gen_dir)/compiler.py',
+  },
+  'rules': [

[Nico, 2012/01/18 17:30:12]

It looks like this rule requires a few variables to be set to be useful. Is
there a way to prevent that?

For example, for --destdir, why can't you use <(INTERMEDIATE_DIR) (or, if you
need these files from multiple targets – which you probably dont
– <(SHARED_INTERMEDIATE_DIR)?

If you can't get rid of all variables, maybe you can add a comment that lists
all variables that need to be set and what they mean? (Kind of like a python
function pydoc string)

[calamity, 2012/01/18 23:46:18]

Yeah, using <(SHARED_INTERMEDIATE_DIR) instead of <(cc_root) works. I wasn't
totally sure what I was doing here so most of it was just taking cues from
build/protoc.gypi.

I could get rid of <(cc_dir) if there's a variable that represents the path to
the directory that the RULE_INPUT file is in. Is there anything like that?

[Nico, 2012/01/18 23:54:42]

Does RULE_INPUT_DIRNAME work?

[calamity, 2012/01/19 00:29:59]

I've looked at the tests for RULE_INPUT_DIRNAME and it really looks like it
should work. But it doesn't. It ends up substituting with nothing.

[Nico, 2012/01/19 00:49:46]

Might be a bug in gyp.

Taking a step back: What do you need this for? To make the outputs not collide
in SHARED_INTERMEDIATE_DIR? Does just using INTERMEDIATE_DIR (which exists for
this very use case) not work?

[calamity, 2012/01/19 00:57:07]

When I use INTERMEDIATE_DIR, the generated files aren't picked up by the the .cc
files in chrome_browser.gypi.

+    {
+      'rule_name': 'genapi',
+      'extension': 'json',
+      'inputs': [
+        '<(api_gen_dir)/code.py',
+        '<(api_gen_dir)/compiler.py',
+        '<(api_gen_dir)/model.py',
+        '<(api_gen_dir)/cc_generator.py',
+        '<(api_gen_dir)/h_generator.py',
+        '<(api_gen_dir)/cpp_type_generator.py',
+        '<@(json_schema_files)',
+      ],
+      'outputs': [
+        '<(cc_dir)/<(RULE_INPUT_ROOT)_api.cc',
+        '<(cc_dir)/<(RULE_INPUT_ROOT)_api.h',
+      ],
+      'action': [
+        'python',
+        '<(api_gen)',
+        '<(RULE_INPUT_PATH)',
+        '--root=<(DEPTH)',
+        '--destdir=<(cc_root)',
+        '--namespace=<(root_namespace)',
+        '<@(json_schema_files)',

[Nico, 2012/01/18 17:30:12]

Why do you need to pass in both <(RULE_INPUT_PATH) and <@(json_schema_files)?

As far as I understand, a rule is something that says "For files with this
'extension', run the following command, to produce the files in 'outputs'". The
input file is set to <(RULE_INPUT_PATH), so where you include this both
<(RULE_INPUT_PATH) and <@(json_schema_files) should be the same file (?)

[calamity, 2012/01/18 23:46:18]

This was a bit of a hack. Each json could have references to other jsons. So the
<(RULE_INPUT_PATH) is the json we're currently generating which outputs
<(RULE_INPUT_ROOT)_api.cc/h. The <@(json_schema_files) are all the jsons that
comprise the model to ensure dependencies are able to be resolved.

[Nico, 2012/01/18 23:54:42]

I see. And you can't just put the dependencies between the json files into the
json files itself, because gyp needs to know about them to rebuild stuff
correctly.

Ok, then keeping this as is and mentioning them in a "how to use this rule"
comment at the top is fine.

+      ],
+      'message': 'Generating C++ code from <(RULE_INPUT_PATH) jsons',
+      'process_outputs_as_sources': 1,
+    },
+  ],
+  'include_dirs': [
+    '<(cc_root)',
+    '<(DEPTH)',
+  ],
+  'dependencies':[
+    '<(DEPTH)/tools/json_schema_compiler/api_gen_util.gyp:api_gen_util',
+  ],
+  'direct_dependent_settings': {
+    'include_dirs': [
+      '<(cc_root)',
+    ]
+  },
+  # This target exports a hard dependency because it generates header
+  # files.
+  'hard_dependency': 1,
+}