[sync] Componentize sync: Part Final: Target 'sync' is now its own component

third_party/protobuf/protobuf.gyp

-# Copyright (c) 2012 The Chromium Authors. All rights reserved.
+# Copyright 2013 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.
 
 {
   'conditions': [
     ['use_system_protobuf==0', {
       'conditions': [
         ['OS!="win"', {
           'variables': {
             'config_h_dir':
@@ skipping 175 matching lines @@
             'include_dirs': [
               '<(config_h_dir)',
               'src',
             ],
             'defines': [
               'GOOGLE_PROTOBUF_NO_RTTI',
               'GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER',
             ],
             # TODO(jschuh): http://crbug.com/167187 size_t -> int.
             'msvs_disabled_warnings': [ 4267 ],
+            # On Win component builds, we must dynamically link protobuf_lite
+            # to targets that directly depend on it in order to avoid linker
+            # warning C4275: "non dll-interface class used as base for
+            # dll-interface class". See the "DLLs vs. static linking" section in
+            # third_party/protobuf/vsprojects/readme.txt.
+            'conditions': [
+              ['OS=="win" and component=="shared_library"', {
+                'defines': [
+                  'LIBPROTOBUF_EXPORTS',
+                  'LIBPROTOC_EXPORTS',
+                  'PROTOBUF_USE_DLLS',
+                ],
+              }],
+            ],

[Ryan Sleevi, 2013/01/23 19:34:36]

This doesn't make sense, since on line 132, you're building protobuf_lite as a
static_library

Perhaps you meant to also update it to be type: <(component)?

And how does this affect builds for host vs target toolsets? I would somehow
expect the host target would need to be a static compile, but target dynamic?

[Raghu Simha, 2013/01/23 20:23:30]

Thanks for bringing this up. I took another look at this change, and it turns
out that we don't actually use any of protobuf_lite's symbols in sync/. The only
reason I had to export them was to suppress the non-dll-interface class warning
on Windows. I can just as easily do that with an entry in
msvs_disabled_warnings, and not have to worry about changing the target type of
protobuf_lite. Let me know what you think.

           },
         },
         # This is the full, heavy protobuf lib that's needed for c++ .proto's
         # that don't specify the LITE_RUNTIME option.  The protocol
         # compiler itself (protoc) falls into that category.
         #
         # DO NOT LINK AGAINST THIS TARGET IN CHROME CODE  --agl
         {
           'target_name': 'protobuf_full_do_not_use',
           'type': 'static_library',
@@ skipping 267 matching lines @@
           'toolsets': ['host', 'target'],
         },
         {
           'target_name': 'py_proto',
           'type': 'none',
         },
       ],
     }],
   ],
 }