[Sync] Make the 'sync' target the one clients should use

[Sync] Make the 'sync' target the one clients should use

Add 'sync_component' target, which combines all the various sync
sublibraries into one library (which will be componentized).

Move 'internal_api/*' files into 'sync_internal_api'.

Rename some sync targets.

Clean up dependents of sync.

Divide sync.gyp into sections.

BUG=136928
TEST=

[akalin, 2012-07-20 21:03:53]

+tim for sync stuff
+rsleevi for gyp stuff

[Ryan Sleevi, 2012-07-20 23:24:49]

nit: I'm not a big fan of "section" divisions in general, but I may be turned by
the C++ classes where there's always "that one file" in a directory where the
author decides to group methods not by the order in the .h file, but by their
sections, even when every other .cc/.h pair in that file/directory/module do
follow the style guide.


There's a whole lot of export_dependent_settings going on, and it's not clear to
me that they're altogether necessary. Unfortunately, tracking whether they're
necessary or not likely involves reading through all of the header files to see
what's applicable.

I think it mostly looks correct, but I was hoping you could confirm the
following:
1) If a target .cc directly includes a .pb.h, it has a dependency on the
sync_proto target
2) If a target .h directly includes a .pb.h:
2.a - If it's an internal/implementation detail file, it does not export
dependencies
2.b - If it is a "public", as in "here, include this" file, it does
export_dependencies
3) That if you substitute "includes a .pb.h" for "includes a header from 2.b",
that the above rules all parse.
4) That in general, export_dependent_settings is not used to hide 'true'
dependencies (that is, if you depend on a targets' classes, you should have it
under dependencies, not relying on it to be exported by some other module)

I think in general things look correct, and I realize that this is in-flux as
you work to componentize. Ideally, removing the .pb.h files from the public
interface could/would go a huge step towards resolving this, but that may be
much more work than the first stages shown here.

A few comments below of points of confusion.

https://chromiumcodereview.appspot.com/10805046/diff/2001/chrome/chrome_tests...
File chrome/chrome_tests.gypi (left):

https://chromiumcodereview.appspot.com/10805046/diff/2001/chrome/chrome_tests...
chrome/chrome_tests.gypi:4024: '../sync/protocol/sync_proto.gyp:sync_proto',
This seems very counter-intuitive to me.

I admit, I haven't looked deeply into the tests, but the all of the dependencies
you're removing, it sounds like you're expecting them to be picked up
transitively via the export_dependent_settings?

Are/do you use any sync-specific types in these tests? I would imagine so,
that's why removing these doesn't seem to make sense.

I think what you have will work, but I tend to think of
export_dependent_settings as an extension of IWYU philosophy  - if you use it,
depend on it. If the sync portion ever /stops/ getting exported, your dependency
is still intact.

WDYT?

https://chromiumcodereview.appspot.com/10805046/diff/2001/net/net.gyp
File net/net.gyp (right):

https://chromiumcodereview.appspot.com/10805046/diff/2001/net/net.gyp#newcode...
net/net.gyp:1573:
'../chrome/app/policy/cloud_policy_codegen.gyp:cloud_policy_proto_compile',
Mind adding a comment here about removing the above hack (
http://crbug.com/119403 )

https://chromiumcodereview.appspot.com/10805046/diff/2001/sync/sync.gyp
File sync/sync.gyp (right):

https://chromiumcodereview.appspot.com/10805046/diff/2001/sync/sync.gyp#newco...
sync/sync.gyp:14: #    ],
Can you explain why it's necessary to export the settings?

Targets should be able to depend just fine. If it's due to codegen/protobuf'ing,
then sync should export the dependency on the protobuf, which will make syncs
dependents coalesce on the protobuf step, rather than around sync.

export_dependent_settings is only necessary if 'your target' is including sync
headers as part of it's interface. Which is the same as any other GYP file.

I'd drop this whole comment block

https://chromiumcodereview.appspot.com/10805046/diff/2001/sync/sync.gyp#newco...
sync/sync.gyp:286: 'protocol/sync_proto.gyp:sync_proto',
Are you directly using/building these protobufs in your target?

It would seem like, as you structured, it should only be depending on sync_core
and only exporting sync_core (eg: drop line 279)

If you /are/ directly using the .pb.h, then I suppose it makes sense.

[akalin, 2012-11-27 23:19:11]

closing this, since rsimha's CL took this over.