ozone: Allow loading the platform implementation from a system library.

ozone: Allow loading the platform implementation from a system library.

The X11 implementation for the ozone platform is built as a separate
library. Chrome will use this platform only if it is available at
runtime. This allows building and testing ozone on the desktop with
the X11 implementation, but deploy the same build on the device without
the X11 implementation and have it running using a more appropriate
platform implementation.

BUG=361137

[sadrul, 2014-05-09 23:19:02]

[ the master CL is: https://codereview.chromium.org/275263002/ ]

[spang, 2014-05-10 02:09:27]

I made a similar attempt to support modular platforms. Everything works
perfectly until you do a static_library build. The static_library build doesn't
work because nothing is exported.

[sadrul, 2014-05-12 01:15:44]

On 2014/05/10 02:09:27, spang wrote:
> I made a similar attempt to support modular platforms. Everything works
> perfectly until you do a static_library build. The static_library build
doesn't
> work because nothing is exported.

Hm. Good point. How about we start with supporting the dev-mode only on
shared_library builds, and find an alternative when we have unblocked the
interested teams. (from my experiments, it looks like it may still be possible
to support this in static_library builds with sufficient refactoring of some
components (e.g. events, ui_base etc.), but I need to experiment more to know
for sure)

[rjkroege, 2014-05-12 12:39:30]

On 2014/05/12 01:15:44, sadrul wrote:
> On 2014/05/10 02:09:27, spang wrote:
> > I made a similar attempt to support modular platforms. Everything works
> > perfectly until you do a static_library build. The static_library build
> doesn't
> > work because nothing is exported.
> 
> Hm. Good point. How about we start with supporting the dev-mode only on
> shared_library builds, and find an alternative when we have unblocked the
> interested teams. (from my experiments, it looks like it may still be possible
> to support this in static_library builds with sufficient refactoring of some
> components (e.g. events, ui_base etc.), but I need to experiment more to know
> for sure)

sadrul@: I thought you'd indicated to me that the X11 ozone platform would
always get built as a separate .so target which was intended to resolve this
issue?

[spang, 2014-05-12 14:50:58]

On 2014/05/12 01:15:44, sadrul wrote:
> On 2014/05/10 02:09:27, spang wrote:
> > I made a similar attempt to support modular platforms. Everything works
> > perfectly until you do a static_library build. The static_library build
> doesn't
> > work because nothing is exported.
> 
> Hm. Good point. How about we start with supporting the dev-mode only on
> shared_library builds, and find an alternative when we have unblocked the
> interested teams. (from my experiments, it looks like it may still be possible
> to support this in static_library builds with sufficient refactoring of some
> components (e.g. events, ui_base etc.), but I need to experiment more to know
> for sure)

What refactoring do you have in mind? The symbol hiding is by design and also
makes chrome load faster. I'm not sure it's worth pursuing exposing gfx, events,
& skia to libraries, because I imagine it will be viewed as a step backwards by
the team.

I do think we should support static_library builds, since that's how the product
is normally built. My suggestion is: Punt on modularizing the OzonePlatform.
Link OzonePlatformX11 statically into libozone, as we've been doing.

Then, in order to support running without X libs, we can run

 ./tools/generate_library_loader/generate_library_loader.py

on those X libs to generate a loader stub. The X11 platform can use this libs
via this loader stub.

If you want, I'm happy to do this conversion myself after you've landed the
platform.

[sadrul, 2014-05-12 22:01:58]

On 2014/05/12 14:50:58, spang wrote:
> What refactoring do you have in mind? The symbol hiding is by design and also
> makes chrome load faster. I'm not sure it's worth pursuing exposing gfx,
events,
> & skia to libraries, because I imagine it will be viewed as a step backwards
by
> the team.

On 2014/05/12 12:39:30, rjkroege wrote:
> sadrul@: I thought you'd indicated to me that the X11 ozone platform would
> always get built as a separate .so target which was intended to resolve this
> issue?

Yep. That's what I have in mind. I am able to build a libozonex.so and load it
from a static_library build after sufficient amount of persuasion (and without
events support for now), without having to build .sos for gfx, events etc. So I
am still hopeful that it should be possible to do this.

[spang, 2014-05-12 22:09:34]

On 2014/05/12 22:01:58, sadrul wrote:
> On 2014/05/12 14:50:58, spang wrote:
> > What refactoring do you have in mind? The symbol hiding is by design and
also
> > makes chrome load faster. I'm not sure it's worth pursuing exposing gfx,
> events,
> > & skia to libraries, because I imagine it will be viewed as a step backwards
> by
> > the team.
> 
> On 2014/05/12 12:39:30, rjkroege wrote:
> > sadrul@: I thought you'd indicated to me that the X11 ozone platform would
> > always get built as a separate .so target which was intended to resolve this
> > issue?
> 
> Yep. That's what I have in mind. I am able to build a libozonex.so and load it
> from a static_library build after sufficient amount of persuasion (and without
> events support for now), without having to build .sos for gfx, events etc. So
I
> am still hopeful that it should be possible to do this.

I would like to understand the persuasion before landing this.