ozone: Fix the way platform tests link ozone

ozone: Fix the way platform tests link ozone

Right now the DRM platform unit tests link ozone as a component, and also
link against the platform classes statically. Linking two copies of the
platform code into the test executable is an ODR violation and undefined
behavior.

The newer wayland platform fixes the issue, but at the cost of exporting
platform internals from ozone. It'd be good to avoid these exports
because it forces us to mark the platform dependency public in GN, which
in turn makes inclusion of platform internals legal from outside ozone
according to GN's dependency checker.

To fix both issues, this creates an new internal //ui/ozone:platform
target which is used by tests to link ozone statically. Only tests will
use it, everyone else will continue to use ozone encapsulated via the
//ui/ozone component.

GYP can do this as well but has a weird quirk: it won't link if there's
no C++ source file in the component target. I added an empty one.

Committed: https://crrev.com/4dc16f302df8ff9a5fa9fd819cd6e85fbe1835ce
Cr-Commit-Position: refs/heads/master@{#376823}

[spang, 2016-02-19 05:20:34]

spang@chromium.org changed reviewers:
+ rjkroege@chromium.org

[spang, 2016-02-19 05:20:35]

on top of https://codereview.chromium.org/1716543003/

[spang, 2016-02-19 05:32:29]

Description was changed from

==========
ozone: Fix the way platform tests link ozone

Right now the DRM platform unit tests link ozone as a component, and also
link against the platform classes statically. Linking two copies of the
platform code into the test executable is an ODR violation and undefined
behavior.

The newer wayland platform fixes the issue, but at the cost of exporting
platform internals from ozone. It'd be good to avoid these exports
because it forces us to mark the platform dependency public in GN, which
in turn makes inclusion of platform internals legal from outside ozone
according to GN's dependency checker.

To fix both issues, this creates an new internal //ui/ozone:platform
target which is used by tests to link ozone statically. Only tests will
use it, everyone else should use the encapsulated version.

GYP can do this as well but has a weird quirk: it won't link if there's
no C++ source file in the component target. I added an empty one.
==========

to

==========
ozone: Fix the way platform tests link ozone

Right now the DRM platform unit tests link ozone as a component, and also
link against the platform classes statically. Linking two copies of the
platform code into the test executable is an ODR violation and undefined
behavior.

The newer wayland platform fixes the issue, but at the cost of exporting
platform internals from ozone. It'd be good to avoid these exports
because it forces us to mark the platform dependency public in GN, which
in turn makes inclusion of platform internals legal from outside ozone
according to GN's dependency checker.

To fix both issues, this creates an new internal //ui/ozone:platform
target which is used by tests to link ozone statically. Only tests will
use it, everyone else will continue to use ozone encapsulated via the
//ui/ozone component.

GYP can do this as well but has a weird quirk: it won't link if there's
no C++ source file in the component target. I added an empty one.
==========

[rjkroege, 2016-02-19 19:06:32]

https://codereview.chromium.org/1717573002/diff/1/ui/ozone/empty.cc
File ui/ozone/empty.cc (left):

https://codereview.chromium.org/1717573002/diff/1/ui/ozone/empty.cc#oldcode5
ui/ozone/empty.cc:5: namespace blink {
The purpose of this file needs a comment.

The use of the blink namespace bothers me. Is the overlap with blink
intentional? I'd anticipate that we will soon have a real blink namespace.

[spang, 2016-02-22 19:42:55]

https://codereview.chromium.org/1717573002/diff/1/ui/ozone/empty.cc
File ui/ozone/empty.cc (left):

https://codereview.chromium.org/1717573002/diff/1/ui/ozone/empty.cc#oldcode5
ui/ozone/empty.cc:5: namespace blink {
On 2016/02/19 19:06:32, rjkroege wrote:
> The purpose of this file needs a comment.
> 
> The use of the blink namespace bothers me. Is the overlap with blink
> intentional? I'd anticipate that we will soon have a real blink namespace.
> 
> 

Just to be clear, the blink thing is a false positive from git's file copy
detection and has nothing to do with my changes.

Added a comment.

[rjkroege, 2016-02-22 20:28:58]

lgtm

https://codereview.chromium.org/1717573002/diff/40001/ui/ozone/empty.cc
File ui/ozone/empty.cc (right):

https://codereview.chromium.org/1717573002/diff/40001/ui/ozone/empty.cc#newcode5
ui/ozone/empty.cc:5: // This empty source file exist to force GYP to link the
nit: exists

[spang, 2016-02-22 21:03:12]

The CQ bit was checked by spang@chromium.org

[spang, 2016-02-22 21:03:12]

The patchset sent to the CQ was uploaded after l-g-t-m from
rjkroege@chromium.org
Link to the patchset: https://codereview.chromium.org/1717573002/#ps60001
(title: "exists")

[commit-bot: I haz the power, 2016-02-22 21:08:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1717573002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1717573002/60001

[commit-bot: I haz the power, 2016-02-22 22:09:07]

Description was changed from

==========
ozone: Fix the way platform tests link ozone

Right now the DRM platform unit tests link ozone as a component, and also
link against the platform classes statically. Linking two copies of the
platform code into the test executable is an ODR violation and undefined
behavior.

The newer wayland platform fixes the issue, but at the cost of exporting
platform internals from ozone. It'd be good to avoid these exports
because it forces us to mark the platform dependency public in GN, which
in turn makes inclusion of platform internals legal from outside ozone
according to GN's dependency checker.

To fix both issues, this creates an new internal //ui/ozone:platform
target which is used by tests to link ozone statically. Only tests will
use it, everyone else will continue to use ozone encapsulated via the
//ui/ozone component.

GYP can do this as well but has a weird quirk: it won't link if there's
no C++ source file in the component target. I added an empty one.
==========

to

==========
ozone: Fix the way platform tests link ozone

Right now the DRM platform unit tests link ozone as a component, and also
link against the platform classes statically. Linking two copies of the
platform code into the test executable is an ODR violation and undefined
behavior.

The newer wayland platform fixes the issue, but at the cost of exporting
platform internals from ozone. It'd be good to avoid these exports
because it forces us to mark the platform dependency public in GN, which
in turn makes inclusion of platform internals legal from outside ozone
according to GN's dependency checker.

To fix both issues, this creates an new internal //ui/ozone:platform
target which is used by tests to link ozone statically. Only tests will
use it, everyone else will continue to use ozone encapsulated via the
//ui/ozone component.

GYP can do this as well but has a weird quirk: it won't link if there's
no C++ source file in the component target. I added an empty one.
==========

[commit-bot: I haz the power, 2016-02-22 22:09:08]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-02-22 22:11:05]

Description was changed from

==========
ozone: Fix the way platform tests link ozone

Right now the DRM platform unit tests link ozone as a component, and also
link against the platform classes statically. Linking two copies of the
platform code into the test executable is an ODR violation and undefined
behavior.

The newer wayland platform fixes the issue, but at the cost of exporting
platform internals from ozone. It'd be good to avoid these exports
because it forces us to mark the platform dependency public in GN, which
in turn makes inclusion of platform internals legal from outside ozone
according to GN's dependency checker.

To fix both issues, this creates an new internal //ui/ozone:platform
target which is used by tests to link ozone statically. Only tests will
use it, everyone else will continue to use ozone encapsulated via the
//ui/ozone component.

GYP can do this as well but has a weird quirk: it won't link if there's
no C++ source file in the component target. I added an empty one.
==========

to

==========
ozone: Fix the way platform tests link ozone

Right now the DRM platform unit tests link ozone as a component, and also
link against the platform classes statically. Linking two copies of the
platform code into the test executable is an ODR violation and undefined
behavior.

The newer wayland platform fixes the issue, but at the cost of exporting
platform internals from ozone. It'd be good to avoid these exports
because it forces us to mark the platform dependency public in GN, which
in turn makes inclusion of platform internals legal from outside ozone
according to GN's dependency checker.

To fix both issues, this creates an new internal //ui/ozone:platform
target which is used by tests to link ozone statically. Only tests will
use it, everyone else will continue to use ozone encapsulated via the
//ui/ozone component.

GYP can do this as well but has a weird quirk: it won't link if there's
no C++ source file in the component target. I added an empty one.

Committed: https://crrev.com/4dc16f302df8ff9a5fa9fd819cd6e85fbe1835ce
Cr-Commit-Position: refs/heads/master@{#376823}
==========

[commit-bot: I haz the power, 2016-02-22 22:11:06]

Patchset 4 (id:??) landed as
https://crrev.com/4dc16f302df8ff9a5fa9fd819cd6e85fbe1835ce
Cr-Commit-Position: refs/heads/master@{#376823}