Get a minimal unit_tests target building and running for iOS

Get a minimal unit_tests target building and running for iOS

This turns on building chrome.gyp for iOS, which includes unit_tests
and all the supporting targets. unit_tests for now only includes
an extremely limited set of tests on iOS; more will be added to the
target as the necessary changes to build them are landed.

To get unit_tests building this CL:
- Adds at least one file to every library target on iOS
  (profile_error_dialog, browser_process, etc.), since a static library
  with no source files will fail to build.
- Temporarily cuts ChromeContentBrowserClient out of
  chrome_test_suite for iOS; that client is very complex and depends
  on a lot of high-level classes, which makes it very difficult to bring
  up at this point.
- Brings up TestingBrowserProcess, since it's needed by
  chrome_test_suite. All the specific high-level classes are trimmed
  out for iOS; pieces will be brought back as they work and are needed,
  but some of the classes there will never be built on iOS.
- Adds an iOS implementation of ChromeContentClient (with a TODO
  to consider merging it with the existing implementation; there's so
  little shared code, and so much plugin code in the existing file, that it's
  not clear if it's worthwhile) since it's needed by chrome_test_suite.
- Gets chrome_paths and chrome_version_info working on iOS, since
  several classes need them and they are trivial to fix.

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

[stuartmorgan, 2012-11-15 12:46:46]

This ended up being bigger than I would have liked due to the tendrils out of
ChromeTestSuite. Let me know if you'd rather I cut some of the pieces of this
out into smaller CLs, but I don't think it's too terrible as is.

[Nico, 2012-11-15 18:01:33]

This looks mostly fine. The chrome_paths file could maybe use a look from
someone familiar with chrome_paths, and testing_brow… looks pretty ugly now (see
comment below). The rest is fine.

nit: "Adds at least one file was added to every library" in CL description
doesn't parse.

https://codereview.chromium.org/11418005/diff/1/chrome/common/chrome_paths.cc
File chrome/common/chrome_paths.cc (right):

https://codereview.chromium.org/11418005/diff/1/chrome/common/chrome_paths.cc...
chrome/common/chrome_paths.cc:163: switch (key) {
Many of these don't make sense on iOS. Are you going to remove some of these
enum values on ios later on?

(I didn't comment on all the case branches that don't make sense on iOS below.)

https://codereview.chromium.org/11418005/diff/1/chrome/common/chrome_paths.cc...
chrome/common/chrome_paths.cc:422: case chrome::DIR_MANAGED_PREFS: {
This constant only exists if defined(OS_MACOSX), so this change should probably
be made in the header too at least.

https://codereview.chromium.org/11418005/diff/1/chrome/common_constants.gyp
File chrome/common_constants.gyp (right):

https://codereview.chromium.org/11418005/diff/1/chrome/common_constants.gyp#n...
chrome/common_constants.gyp:71: # re-add it in target_conditionals so it's after
that exclusion.
Is there a file name rule for files that are used on both mac and ios?

It's a bit confusing that _mac.mm is excluded on iOS, but OS_MACOSX is
apparently true on iOS.

https://codereview.chromium.org/11418005/diff/1/chrome/test/base/testing_brow...
File chrome/test/base/testing_browser_process.cc (right):

https://codereview.chromium.org/11418005/diff/1/chrome/test/base/testing_brow...
chrome/test/base/testing_browser_process.cc:71: #if defined(OS_IOS)
This file looks pretty forked now. Do you think it would make sense to have a
testing_browser_process_ios.cc that's used on iOS instead of this file? (Or
maybe have this file contain all common methods, and move only the forked
functions to different files. I think we prefer filename rules over ifdefs.)

[stuartmorgan, 2012-11-15 18:23:11]

https://codereview.chromium.org/11418005/diff/1/chrome/common/chrome_paths.cc
File chrome/common/chrome_paths.cc (right):

https://codereview.chromium.org/11418005/diff/1/chrome/common/chrome_paths.cc...
chrome/common/chrome_paths.cc:163: switch (key) {
On 2012/11/15 18:01:33, Nico wrote:
> Many of these don't make sense on iOS. Are you going to remove some of these
> enum values on ios later on?

There's no specific plan to, since in many cases the code is harmless, but I'm
happy to file a bug and do a follow up if you think we should. I figured fewer
ifdefs was better, but I guess there is precedent for ifdef soup here.

The ifdefs here are for Mac code that doesn't compile because it's only
meaningful on Mac.

https://codereview.chromium.org/11418005/diff/1/chrome/common/chrome_paths.cc...
chrome/common/chrome_paths.cc:422: case chrome::DIR_MANAGED_PREFS: {
On 2012/11/15 18:01:33, Nico wrote:
> This constant only exists if defined(OS_MACOSX), so this change should
probably
> be made in the header too at least.

Good point. I'll do a sweep tomorrow on the header and this file and change all
the relevant #defines even where it's not a compile issue, to follow the
structure that's already there, and then update this CL.

https://codereview.chromium.org/11418005/diff/1/chrome/common_constants.gyp
File chrome/common_constants.gyp (right):

https://codereview.chromium.org/11418005/diff/1/chrome/common_constants.gyp#n...
chrome/common_constants.gyp:71: # re-add it in target_conditionals so it's after
that exclusion.
On 2012/11/15 18:01:33, Nico wrote:
> Is there a file name rule for files that are used on both mac and ios?

No. I spoke to Mark about this quite a while ago, and suggested _apple, but he
was strongly opposed and wanted us to just include specific _mac files.

> It's a bit confusing that _mac.mm is excluded on iOS, but OS_MACOSX is
> apparently true on iOS.

Agreed, but our feeling is that the alternative is worse. There's a whole lot of
_mac and /mac/ files that we don't want, and re-excluding them would be more
painful that doing targeted includes. OS_MACOSX and OS_IOS follows the Apple
convention used for availability macro headers, where OS X is always true, even
on iOS. And within files we do use, MACOSX is often the right thing for us,
since there is a lot of shared code in Foundation and such.

I can try to get numbers on both the ifdef and the files if you want, and we can
re-open the discussion. I really don't think we should make our macros work
differently than the exactly corresponding Apple macros though.

https://codereview.chromium.org/11418005/diff/1/chrome/test/base/testing_brow...
File chrome/test/base/testing_browser_process.cc (right):

https://codereview.chromium.org/11418005/diff/1/chrome/test/base/testing_brow...
chrome/test/base/testing_browser_process.cc:71: #if defined(OS_IOS)
On 2012/11/15 18:01:33, Nico wrote:
> This file looks pretty forked now. Do you think it would make sense to have a
> testing_browser_process_ios.cc that's used on iOS instead of this file? (Or
> maybe have this file contain all common methods, and move only the forked
> functions to different files. I think we prefer filename rules over ifdefs.)

About 50% of this is temporary, because we have a bootstrapping problem: I want
to get unit_tests up early so as we bring code up we can enable the
corresponding tests, but unit_tests depends on this and this depends on a bunch
of high-level classes that would take a lot of layers to bring up.

In the final state, I don't think the ifdefing rises to the level of needing to
refactor the file, and I don't think we should split and then re-merge just for
the temporary state. But if you think half this number of ifdefs is still too
many, we can do a split.

[Nico, 2012-11-15 18:27:22]

https://codereview.chromium.org/11418005/diff/1/chrome/common_constants.gyp
File chrome/common_constants.gyp (right):

https://codereview.chromium.org/11418005/diff/1/chrome/common_constants.gyp#n...
chrome/common_constants.gyp:71: # re-add it in target_conditionals so it's after
that exclusion.
On 2012/11/15 18:23:11, stuartmorgan wrote:
> On 2012/11/15 18:01:33, Nico wrote:
> > Is there a file name rule for files that are used on both mac and ios?
> 
> No. I spoke to Mark about this quite a while ago, and suggested _apple, but he
> was strongly opposed and wanted us to just include specific _mac files.
> 
> > It's a bit confusing that _mac.mm is excluded on iOS, but OS_MACOSX is
> > apparently true on iOS.
> 
> Agreed, but our feeling is that the alternative is worse. There's a whole lot
of
> _mac and /mac/ files that we don't want, and re-excluding them would be more
> painful that doing targeted includes. OS_MACOSX and OS_IOS follows the Apple
> convention used for availability macro headers, where OS X is always true,
even
> on iOS. And within files we do use, MACOSX is often the right thing for us,
> since there is a lot of shared code in Foundation and such.
> 
> I can try to get numbers on both the ifdef and the files if you want, and we
can
> re-open the discussion. I really don't think we should make our macros work
> differently than the exactly corresponding Apple macros though.

It's ok, I was just curious.

[Nico, 2012-11-15 18:30:13]

ok, lgtm

https://codereview.chromium.org/11418005/diff/1/chrome/test/base/testing_brow...
File chrome/test/base/testing_browser_process.cc (right):

https://codereview.chromium.org/11418005/diff/1/chrome/test/base/testing_brow...
chrome/test/base/testing_browser_process.cc:71: #if defined(OS_IOS)
On 2012/11/15 18:23:11, stuartmorgan wrote:
> On 2012/11/15 18:01:33, Nico wrote:
> > This file looks pretty forked now. Do you think it would make sense to have
a
> > testing_browser_process_ios.cc that's used on iOS instead of this file? (Or
> > maybe have this file contain all common methods, and move only the forked
> > functions to different files. I think we prefer filename rules over ifdefs.)
> 
> About 50% of this is temporary, because we have a bootstrapping problem: I
want
> to get unit_tests up early so as we bring code up we can enable the
> corresponding tests, but unit_tests depends on this and this depends on a
bunch
> of high-level classes that would take a lot of layers to bring up.
> 
> In the final state, I don't think the ifdefing rises to the level of needing
to
> refactor the file, and I don't think we should split and then re-merge just
for
> the temporary state. But if you think half this number of ifdefs is still too
> many, we can do a split.

I guess we can look at this once the temporary ifdefs are gone.

[stuartmorgan, 2012-11-16 08:33:44]

Fixed up the ifdefs to be consistent between the .cc and .h in the paths files,
and filed crbug.com/161448 for the rest of the enums.

[commit-bot: I haz the power, 2012-11-16 09:19:12]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/stuartmorgan@chromium.org/11418005/1016

[commit-bot: I haz the power, 2012-11-16 11:22:04]

Change committed as 168188