Linux: fix header includes for system protobuf.

Linux: fix header includes for system protobuf.

BUG=157155
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=168945

[Paweł Hajdan Jr., 2012-11-20 22:08:42]

Please review:

thestig: chrome & third_party/protobuf
wez: remoting
satorux: dbus

[Wez, 2012-11-20 22:12:06]

On 2012/11/20 22:08:42, Paweł Hajdan Jr. wrote:
> Please review:
> 
> thestig: chrome & third_party/protobuf
> wez: remoting
> satorux: dbus

For other third-party projects we add a shim header in third_party for Chrome
code to use, which does the job of switching between the third-party and system
copies; why not do that for protobuf too?

[Paweł Hajdan Jr., 2012-11-20 22:17:20]

protobuf has multiple headers. We use convention in this patch for other libs,
e.g. zlib.

[satorux1, 2012-11-20 22:32:11]

I'm not sure if we want to use the system protobuf. IIRC, the one in third_party
is new and "static initializers" free (thakis knows more), whereas the system
protobuf may still have this problem...

Besides, protobuf-lite is very small IIRC. What's the benefit of using the
system protobuf?

[Lei Zhang, 2012-11-20 22:35:39]

On 2012/11/20 22:17:20, Paweł Hajdan Jr. wrote:
> protobuf has multiple headers. We use convention in this patch for other libs,
> e.g. zlib.

I'm ok either way.

[Paweł Hajdan Jr., 2012-11-20 22:39:30]

On 2012/11/20 22:32:11, satorux1 wrote:
> I'm not sure if we want to use the system protobuf. IIRC, the one in
third_party
> is new and "static initializers" free (thakis knows more), whereas the system
> protobuf may still have this problem...

Please don't worry. We'll continue to use the bundled one for Google Chrome, and
everything you're going to use.

> Besides, protobuf-lite is very small IIRC. What's the benefit of using the
> system protobuf?

Good question. The benefit is not using a bundled library. See
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries for more info.

[Nico, 2012-11-20 22:47:24]

On 2012/11/20 22:32:11, satorux1 wrote:
> I'm not sure if we want to use the system protobuf. IIRC, the one in
third_party
> is new and "static initializers" free (thakis knows more), whereas the system
> protobuf may still have this problem...

Sync depends on the lite runtime retaining unknown fields, something the system
protobuf library doesn't do. Will this break sync on distributions that opt to
use the system library?

> 
> Besides, protobuf-lite is very small IIRC. What's the benefit of using the
> system protobuf?

[Paweł Hajdan Jr., 2012-11-20 23:13:03]

On 2012/11/20 22:47:24, Nico wrote:
> On 2012/11/20 22:32:11, satorux1 wrote:
> > I'm not sure if we want to use the system protobuf. IIRC, the one in
> third_party
> > is new and "static initializers" free (thakis knows more), whereas the
system
> > protobuf may still have this problem...
> 
> Sync depends on the lite runtime retaining unknown fields, something the
system
> protobuf library doesn't do. Will this break sync on distributions that opt to
> use the system library?

Nope. The distros will use the full protobuf library.

In case you wonder how it's going to interact with existing options like
optimize for PROTO_LITE and retain_unknown_fields: distros will have to sed
those out.

[Lei Zhang, 2012-11-20 23:20:33]

lgtm assuming Satoru-san is happy with this CL.

[satorux1, 2012-11-20 23:59:55]

LGTM. I don't know if following the distros policy is worth adding the
complexity (sed solution sounds awful), but the changes to #includes are minor
enough.

[Wez, 2012-11-21 00:01:45]

lgtm remoting/, if everyone else is happy with this approach.

[commit-bot: I haz the power, 2012-11-21 00:20:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/phajdan.jr@chromium.org/11418102/1

[commit-bot: I haz the power, 2012-11-21 01:34:56]

Change committed as 168945