Remove hand-rolled protobufs generation; enable rel paths in protoc.gypi

build/protoc.gypi

 # Copyright (c) 2011 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.
 
 # This file is meant to be included into an target to provide a rule
 # to invoke protoc in a consistent manner.
 #
 # To use this, create a gyp target with the following form:
 # {
 #   'target_name': 'my_proto_lib',
@@ skipping 25 matching lines @@
 # A proto_out_dir of foo/bar produces
 #   <(SHARED_INTERMEDIATE_DIR)/protoc_out/foo/bar/{file1,file2}.pb.{cc,h}
 #   <(SHARED_INTERMEDIATE_DIR)/pyproto/foo/bar/{file1,file2}_pb2.py
 
 {
   'variables': {
     'protoc': '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)protoc<(EXECUTABLE_SUFFIX)',
     'cc_dir': '<(SHARED_INTERMEDIATE_DIR)/protoc_out/<(proto_out_dir)',
     'py_dir': '<(PRODUCT_DIR)/pyproto/<(proto_out_dir)',
     'proto_in_dir%': '.',
+    'proto_relpath%': '.',

[Ryan Sleevi, 2012/02/13 19:32:12]

Can you not define proto_relpath as '', and let child-implementations include
the trailing slash?

[KushalP, 2012/02/14 11:36:07]

I could, but then that doesn't follow the idioms of how paths appear to be used
elsewhere: they don't require the trailing slash.

I'm fine with doing it if you feel it's the correct route to go. Just pointing
out something I've observed.

[Ryan Sleevi, 2012/02/15 20:15:29]

You should be able to make this at least '' rather than '.'

The only reason proto_in_dir is '.' is because it acts as the leading component
for some variables (namely, the call to protoc), so a '/foo' would be bad.
Having a variable expand to './/' should work no different than '././', although
I don't feel strongly about it one way or the other.

   },
   'rules': [
     {
       'rule_name': 'genproto',
       'extension': 'proto',
       'inputs': [
         '<(protoc)',
       ],
       'outputs': [
-        '<(py_dir)/<(RULE_INPUT_ROOT)_pb2.py',
-        '<(cc_dir)/<(RULE_INPUT_ROOT).pb.cc',
-        '<(cc_dir)/<(RULE_INPUT_ROOT).pb.h',
+        '<(py_dir)/<(proto_relpath)/<(RULE_INPUT_ROOT)_pb2.py',

[Ryan Sleevi, 2012/02/13 19:32:12]

So this becomes
<(py_dir)/<(proto_relpath)<(RULE_INPUT_ROOT)_pb2.py

etc

+        '<(cc_dir)/<(proto_relpath)/<(RULE_INPUT_ROOT).pb.cc',
+        '<(cc_dir)/<(proto_relpath)/<(RULE_INPUT_ROOT).pb.h',
       ],
       'action': [
         '<(protoc)',
         '--proto_path=<(proto_in_dir)',
         # Naively you'd use <(RULE_INPUT_PATH) here, but protoc requires
         # --proto_path is a strict prefix of the path given as an argument.
-        '<(proto_in_dir)/<(RULE_INPUT_ROOT)<(RULE_INPUT_EXT)',
+        '<(proto_in_dir)/<(proto_relpath)/<(RULE_INPUT_ROOT)<(RULE_INPUT_EXT)',
         '--cpp_out=<(cc_dir)',
         '--python_out=<(py_dir)',
         ],
       'message': 'Generating C++ and Python code from <(RULE_INPUT_PATH)',
       'process_outputs_as_sources': 1,
     },
   ],
   'dependencies': [
     '<(DEPTH)/third_party/protobuf/protobuf.gyp:protoc#host',
     '<(DEPTH)/third_party/protobuf/protobuf.gyp:protobuf_lite',
   ],
   'include_dirs': [
     '<(SHARED_INTERMEDIATE_DIR)/protoc_out',
   ],
   'direct_dependent_settings': {
     'include_dirs': [
       '<(SHARED_INTERMEDIATE_DIR)/protoc_out',
     ]
   },
   'export_dependent_settings': [
     # The generated headers reference headers within protobuf_lite,
     # so dependencies must be able to find those headers too.
     '<(DEPTH)/third_party/protobuf/protobuf.gyp:protobuf_lite',
   ],
   # This target exports a hard dependency because it generates header
   # files.
   'hard_dependency': 1,
 }