Enabling Mojo on iOS

[Colin Blundell]

Hi all,

I would like to enable Mojo on iOS. I have a CL that does so here [note: not intended for submission in its current form]. This CL excludes the following:

- Parts of Mojo related to sandboxing/multiprocessing/OpenGL (which we cannot support on iOS due to platform limitations).

- Javascript support (which we definitely want to support, but is an open challenge at this time due to the fact that we don't use V8 on iOS).

All enabled unittests/perftests pass on iOS.

I have several questions for the Mojo community:

- Is there support for enabling Mojo on iOS? Are there questions that people would like to resolve before moving forward with this?

- Are there any pieces of functionality that I haven't brought up that seem like they could/should be enabled on iOS?

- Assuming that that there is support for this effort at this time, would anyone be up for taking the lead on working through a desired structure for the gypfiles in order to turn the linked CL into something landable?

Once the above CL lands, I would have the mojo unittests added to the iOS Chromium bots ASAP.

Thanks to all,

Colin

[Viet-Trung Luu]

I'm generally supportive of the idea of Mojo on iOS, but I'm concerned about the development overhead that it'd impose at this early stage, when things are still evolving rapidly.

(Basically, just keeping things building on configurations that are significantly different from, say, Linux desktop is a significant burden.[*] Such configurations either impose an extreme reliance on trybots, with eternal turnaround times, or the cost of making local builds, with the learning/maintenance/context switch burdens that entails.)

At some point, when we switch more of Chromium to use Mojo, it'll become necessary, but I'd put it off as long as possible -- at least a few months, say. If we want to get it up and running before then, I'd suggest only building/running on an FYI bot.

[*] This applies to all the platforms that we already support, with Android and Windows being the most costly; support on Android is basically currently only at the "best-effort" level (since we basically (?) don't run tests there).

To unsubscribe from this group and stop receiving emails from it, send an email to mojo-dev+u...@chromium.org.

[Colin Blundell]

Thanks. I understand that concern. Given the unique requirements of iOS, I'm afraid of Mojo evolving in a way such that it becomes very difficult to support on iOS, and we end up again in a situation like the one we're in wrt //content at the current time where it's decided that the cleanest thing to do is to have iOS not use Mojo :\.

Thanks,

Colin

[Colin Blundell]

Maybe building/running on an FYI bot *is* a reasonable middle ground? The burden would then be off the Mojo developers, but I (on behalf of the iOS port) would still be able to monitor the evolution of Mojo on iOS, make fixes, and start discussions if real incompatibilities started to arise.

Thanks,

Colin

[Darin Fisher]

One thing I've noticed is that the IOS build blows up if any generated .mojom.h files are included. It would be nice if that weren't the case. My concern is that as we start using mojo more and more in src/content/ and src/chrome/, we may end up breaking the IOS build a bunch. It is really painful when it happens. It would be nice if including .mojom.h files did not create problems for the IOS build. The main issue I ran into is that the targets for the .mojom.h files somehow brings in a dependency on V8. That is probably trivial to resolve. I just haven't taken the time to figure it out yet. Help would be most appreciated!

-Darin

[Colin Blundell]

Hi Darin,

Yep, I'll look into this.

Thanks,

Colin

[Colin Blundell]

Hi Darin,

Do you have an example offhand that I could use as a test case?

Thanks,

Colin

[Darin Fisher]

See child_thread.h. I had to add some more #ifdefs to prevent the IOS build from seeing that header file.

-Darin

[Colin Blundell]

Hi Darin,

Circling back on this: It's adding a gyp dependency on a target (any target) in mojo.gyp on iOS that causes a problem. The reason is that some of the targets in mojo.gyp depend on targets in v8.gyp, so when gyp processes mojo.gyp it ends up looking for v8.gyp...which isn't present on iOS because src/v8 is set to None on iOS.

The answer IMO is to do some surgery on mojo.gyp (and the associated .gypi files if needed) in order to separate out the targets into ones that make sense for iOS (e.g., mojo_cpp_bindings) and ones that don't, similar as we've done for other gypfiles in the codebase. https://codereview.chromium.org/264563005/ provides a good starting point as to which buckets the various targets belong in. I can do that work at any point; per the earlier discussion in this thread, I'm not sure when we'd be ready to land those changes.

Thanks,

Colin

On Wed, Apr 30, 2014 at 7:29 PM, Darin Fisher <da...@chromium.org> wrote:

[Darin Fisher]

Sounds like a good plan.

Thanks!
-Darin

[Colin Blundell]

https://codereview.chromium.org/360563004/

Thanks,

Colin

[Colin Blundell]

As a followup question, are people ok with making the test targets enabled on iOS in https://codereview.chromium.org/360563004/ tree-closers on iOS once that CL lands? As anecdotal evidence of their stability on iOS, all those tests passed on iOS when I first experimented with Mojo support on iOS two months ago, and all of them passed when I returned to the issue of Mojo support on iOS last week.

Thanks,

Colin

[James Robinson]

On Tue, Jul 1, 2014 at 11:45 AM, Colin Blundell <blun...@chromium.org> wrote:

As a followup question, are people ok with making the test targets enabled on iOS in https://codereview.chromium.org/360563004/ tree-closers on iOS once that CL lands?

What does 'tree-closers on iOS' mean?  There aren't any iOS bots on build.chromium.org, as far as I know.

- James

[Colin Blundell]

There are iOS bots on build.chromium.org, e.g., http://build.chromium.org/p/chromium.mac/builders/iOS%20Simulator%20(dbg). I'm proposing having the mojo tests run on trybots/CQ/main waterfall/gatekeeper on iOS.

Thanks,

Colin

[Darin Fisher]

I think it would be better to propose new tree closers on chromium-dev@.

-Darin

[Colin Blundell]

SGTM, I'll revisit this question on chromium-dev@ once we resolve the introduction of initial Mojo support on iOS.

Thanks,

Colin