Merge lp://qastaging/~alan-griffiths/mir/deduplicate-platform-plugin-symbols-maps into lp://qastaging/mir

PASSED: Continuous integration, rev:1830
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-ci/2342/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/1244
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-utopic-amd64-build/1250
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-utopic-touch/1233
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/864
        deb: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/864/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-armhf-ci/865
        deb: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-armhf-ci/865/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-utopic-armhf/168
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-utopic-armhf/168/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2343

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/2342/rebuild

Hm. I'm not sure this is a good idea. The mesa and android client platforms export different symbols; do we want to tie them together?

It *seems* to work. Although I agree we should be concerned about mentioning "mesa" in non-mesa platforms...

$ cat mesa/symbols.map
MIR_CLIENTPLATFORM_1 {
  global:
    create_client_platform_factory;
    # Needed by our Mesa EGL platform
    mir_client_mesa_egl_native_display_is_valid;
  local: *;
};

Oh, yeah. It *works*. I just didn't think it was a good idea :)

*Needs discussion*

I think that our (or anyone else's) platform plugins /ought/ to conform to a common interface.

They don't and this discussion makes it painfully obvious.

Is it necessary for "our Mesa EGL platform" to rely on this export or is that a wart we should remove at some point?

IIRC, the mir_client_mesa_egl_native_display_is_valid needs exporting because there isn't a way to get this information via the EGLNativeWindowType (or EGLNativeDisplayType) for mesa. The proper fix is probably to root out that function in mesa egl, and add an info-gathering path via the native types.
Its definitely a wart, but I'm okay with it until we can get around fixing the mesa egl. The bulk of the platform stuff is hidden behind the generic symbols

One solution would be to drop the local: *; stanza. Then we've got a symbols.map that specifies the interface we care about, without breaking others.

> I think that our (or anyone else's) platform plugins /ought/ to conform to a common interface.

They do conform to a common interface from Mir's point of view: they export create_client_platform_factory. However, they may need to conform to other interfaces too, required for hardware platform integration.

> One solution would be to drop the local: *; stanza.

That would defeat the main goal of the symbol map in this case, which is to reduce the number of exported symbols to the minimum possible.

Only platform plugins themselves know what they need to export to keep both Mir and the hardware platform happy, and this should be expressed inside the (build) code of each platform plugin.

I am OK with completely separate version scripts for now, but another option is for the plugins to start with a common symbol map template (e.g. src/client/pluginsymbols.map.in just exporting what mir needs which is currently create_client_platform_factory), and be able to extend that with any symbols they need for hardware platform integration:

MIR_CLIENTPLATFORM_1 {
  global:
    create_client_platform_factory;
    $PLATFORM_SPECIFIC_EXPORTS
  local: *;
};

// Or a custom clause if we don't platform specific exports to be versioned with MIR ABI?
// Not sure how/if version scripts support this.
// $PLATFORM_SPECIFIC_EXPORTS_CLAUSE

> I am OK with completely separate version scripts for now, but another option

Me too