New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 608017 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Clean up //mojo

Project Member Reported by ben@chromium.org, Apr 29 2016

Issue description

There's a lot of cruft in //mojo.

Quick breakdown:

android/          <-- what's this for?
build/            <-- seems old, obsolete?
common/           <-- Ken asks if this should be part of the public client lib.
converters/       <-- layering violation, should be elsewhere in tree
gles2/, gpu/      <-- ??
logging/          <-- unnecessary with base/logging?
platform_handle/  <-- move to common/ client lib?
test/             <-- what's all this then?
util/             <-- move elsewhere

Seems like this directory could use vacuuming.
 

Comment 1 by roc...@chromium.org, Apr 29 2016

IIRC mojo/android is EDK runtime support for Java. It's required for Java
code to use mojo primitives and bindings.

build/ can go away

I'd like to lump common and utils together (public/cpp/utils?)

test/ should at best move to public/cpp/test_support

logging/ can go away - its only users are apptests (dead) and mojo:media,
but either way it doesn't belong in //mojo

platform_handle/ is tricky. It's like a client library, but it has a
dependency on non-public EDK API surface. This makes linking against it...
interesting. As such it's a bit more special than the rest of the client
libs which are all implemented entirely on public mojo APIs. We ought to
add similar support for wrapping/unwrapping base::SharedMemoryHandle, and
that will also require non-public EDK API usage. I'd be interested to hear
proposals on how to lump these things together in some meaningful way.

I agree on converters/ being in the wrong place.

gpu and gles2 seem like they belong together, but i don't see a great place
to combine them (other than gpu itself.) gles2 does depend on
platform_handle which makes it special as far as things in //mojo go.

The README is also conveying the wrong information at this point :)

Comment 2 by ben@chromium.org, May 25 2016

Given your description, should mojo/android live under mojo/edk/android?

Comment 3 by roc...@chromium.org, May 25 2016

Yes, I think that makes sense
Components: Internals>Mojo

Comment 7 Deleted

Comment 8 by roc...@chromium.org, May 29 2017

Cc: -amistry@chromium.org
Status: Fixed (was: Available)
Calling this fixed. All that's left is mojo/common which is all base:: typemapping stuff, and there's already a separate bug to track moving this to //base/mojom.

Sign in to add a comment