Mojo: Eliminate duplicate C API symbols

Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
now both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=612500
Committed: https://crrev.com/464e306a82ead839f02f1930a684400228b72495
Cr-Commit-Position: refs/heads/master@{#398605}

[Ken Rockot(use gerrit already), 2016-06-08 08:29:36]

Description was changed from

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, allowing targets to be linked against
mojo/public libraries without requiring additional
EDK dependencies at build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the
MojoSetSystemThunks call used by the native app loader)
for setting these thunks.

Also some opportunistic cleanup of Mojo build rules.

BUG=None
==========

to

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks.

Because mojo/public/c/system is a component and
mojo/edk/system is as well, and because there are no
longer redundant exports between the two, it's now
safe for targets to depend on either one or both of
them as needed.

Also some opportunistic cleanup of Mojo build rules.

BUG=None
==========

[Ken Rockot(use gerrit already), 2016-06-08 14:44:32]

Description was changed from

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks.

Because mojo/public/c/system is a component and
mojo/edk/system is as well, and because there are no
longer redundant exports between the two, it's now
safe for targets to depend on either one or both of
them as needed.

Also some opportunistic cleanup of Mojo build rules.

BUG=None
==========

to

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
no both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=None
==========

[Ken Rockot(use gerrit already), 2016-06-08 14:50:19]

Patchset #2 (id:20001) has been deleted

[Ken Rockot(use gerrit already), 2016-06-08 14:50:26]

Patchset #1 (id:1) has been deleted

[Ken Rockot(use gerrit already), 2016-06-08 14:56:07]

rockot@chromium.org changed reviewers:
+ jam@chromium.org

[Ken Rockot(use gerrit already), 2016-06-08 14:56:08]

The sync patch kept exploding in size. Even with a separate channel target,
because of ASAN build linkage, it was approaching 30 targets needing an update.
I just don't think it's acceptable to add //mojo/edk/system to that many
targets.

So here's a fix to the stupid dependency problem. The C API now behaves like any
other sane dependency in src and you can link against it without needing to link
against the EDK. Of course a process still needs to call mojo::edk::Init before
it can use the functions at runtime, but this eliminates the awkward build rule
constraints.

[Ken Rockot(use gerrit already), 2016-06-08 14:57:35]

Description was changed from

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
no both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=None
==========

to

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
now both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=None
==========

[jam, 2016-06-08 15:44:28]

Description was changed from

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
now both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=None
==========

to

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
now both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=612500
==========

[jam, 2016-06-08 16:04:16]

lgtm

https://codereview.chromium.org/2044023004/diff/40001/mojo/edk/embedder/entry...
File mojo/edk/embedder/entrypoints.h (right):

https://codereview.chromium.org/2044023004/diff/40001/mojo/edk/embedder/entry...
mojo/edk/embedder/entrypoints.h:14: MOJO_SYSTEM_IMPL_EXPORT MojoSystemThunks
MakeSystemThunks();
nit: add comment

[Ken Rockot(use gerrit already), 2016-06-08 16:14:13]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-06-08 16:14:13]

The patchset sent to the CQ was uploaded after l-g-t-m from jam@chromium.org
Link to the patchset: https://codereview.chromium.org/2044023004/#ps80001
(title: "nit")

[commit-bot: I haz the power, 2016-06-08 16:14:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2044023004/80001

[commit-bot: I haz the power, 2016-06-08 17:21:56]

Description was changed from

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
now both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=612500
==========

to

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
now both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=612500
==========

[commit-bot: I haz the power, 2016-06-08 17:21:57]

Committed patchset #3 (id:80001)

[commit-bot: I haz the power, 2016-06-08 17:23:47]

Description was changed from

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
now both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=612500
==========

to

==========
Mojo: Eliminate duplicate C API symbols

This gets rid of the duplicate definitions of public
Mojo C API symbols, instead making mojo/public/c/system
the singular source of these definitions. This allows
targets to be linked against mojo/public libraries
without requiring any additional EDK dependencies at
build time.

To facilitate this the EDK uses the same set of API
thunks as the public library, and the public library
exposes a special embedder API (distinct from the DSO
MojoSetSystemThunks call used by the native app loader)
for setting these thunks. The MojoSetSystemThunks API
is moved to a module which is only linked directly into
app DSOs.

Because mojo/public/c/system and mojo/edk/system are
now both components, and because there are no longer
redundant exports between the two, it's now safe for
targets to depend on either one or both of them as
needed without encountering duplicate definitions.

Also some opportunistic cleanup of Mojo build rules.

BUG=612500

Committed: https://crrev.com/464e306a82ead839f02f1930a684400228b72495
Cr-Commit-Position: refs/heads/master@{#398605}
==========

[commit-bot: I haz the power, 2016-06-08 17:23:48]

Patchset 3 (id:??) landed as
https://crrev.com/464e306a82ead839f02f1930a684400228b72495
Cr-Commit-Position: refs/heads/master@{#398605}

[Ken Rockot(use gerrit already), 2016-06-08 17:58:44]

A revert of this CL (patchset #3 id:80001) has been created in
https://codereview.chromium.org/2047813003/ by rockot@chromium.org.

The reason for reverting is: tentative revert due to linker errors. this doesn't
make sense. nothing makes sense. RIP sanity.