Separates ipc code from common (http://crbug.com/16829)

This splits the ipc code from the common project.  The 'common' project pulls in all of webkit, the v8 bindings, skia, googleurl, and a number of other projects which makes it very difficult to deal with especially for external projects wanting just to use some of Chromium's infrastructure.  This puts the ipc code into its top-level ipc/ directory with a dependency only on base.  The common project depends on the new ipc/ipc.gyp:ipc target so that all projects currently pulling common in to get the IPC code still have it available.  This mostly follows agl's pre-gyp attempt to do this which was r13062.

Known issues:
- Currently a number of projects depend on chrome/chrome.gyp:common in order to use the IPC infrastructure.  Rather than fixing all of these dependencies I have made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules section of DEPS so that checkdeps.py doesn't complain.  Over time projects that need IPC should depend on the IPC project themselves and dependencies on common removed, although I don't think many projects that need IPC will be able to get away without common currently.
- ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a #if 0 block because of http://crbug.com/7828 even though logically files within ipc/ should not refer to files in chrome/... now.  I'm not sure how to resolve this since it's really an IDE bug
- the named pipe name (windows+linux) and the logging event name (all) + env variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion of ipc/ being an independent library.  I think this should be examined in a subsequent, much smaller patch.
- I've eliminated the IPC.SendMsgCount counter since it was implemented in a way to create a dependency from ipc/ to chrome/common/chrome_counters. This is the same approach that r13062 took.

[jamesr1, 2009-07-22 18:05:43]

Passes all try bots.

[agl, 2009-07-22 18:16:08]

chrome_descriptor.h probably shouldn't be moved. I'm also unsure about
file_descriptor_set.

Can you email a link to the `git diff -C -M master`? I cna't review this change
in its current form.


Cheers

[jamesr1, 2009-07-22 18:33:22]

On Wed, Jul 22, 2009 at 11:16 AM, <agl@chromium.org> wrote:

> chrome_descriptor.h probably shouldn't be moved. I'm also unsure about
> file_descriptor_set.


FileDescriptorSet seems to logically be a container for FDs that is used in
the IPC system but is not chromium-specific in any way.

I'll split chrome_descriptor.h up per our IRC discussion.


>
>
> Can you email a link to the `git diff -C -M master`? I cna't review this
> change in its current form.


Will do after fixing the descriptor issue and updating the header guards I
missed.

- James


>
>
>
> Cheers
>
>
> http://codereview.chromium.org/155905
>

[jamesr1, 2009-07-22 20:54:32]

Patch updated.  I've also added a list of Known Issues with this patch to the
description, let me know if anything there is too frightening.

agl: I sent you a pointer to a git diff -C -M patch via chat.  I unfortunately
don't have any easily accessible external webspace to dump a patch on, but the
contents are the same as the ones here on rietveld (just hopefully a bit easier
to look at).

[agl, 2009-07-22 21:09:18]

Darin still needs to OK it, but LGTM.

I should note that the Reitveld change looks worse than it is: at commit time,
Git will find the file moves and do the correct thing.

[darin (slow to review), 2009-07-22 22:18:31]

I recently added common/webkit_param_traits.h.  I think that is a better file
name than say webkit_message_utils.h.  How about renaming common_message_utils.h
to common_param_traits.h?  (I'm not crazy about the common prefix either, but I
don't have a better suggestion at the moment.)

It would be good to put a comment at the top of the common_param_traits.h file
giving guidelines about what should or should not go into that file.  I think
the answer is that only param traits shared by more than one child process
should go in there.

Otherwise, LGTM

[M-A Ruel, 2009-08-04 16:57:39]

On 2009/07/22 22:18:31, darin wrote:
> Otherwise, LGTM

YOU FORGOT TO SVN:IGNORE THE GENERATED PROJECT FILES. (I'll do because
you're not alone)