Merge lp:~vanvugt/mir/fix-1192908 into lp:~mir-team/mir/trunk

[Daniel van Vugt]

Break the cyclic dependency we have between Mir and Mesa (libEGL) that's
preventing builds from working at all on many systems (LP: #1192908)

This allows Mir to build against any version of libEGL/Mesa. And then Mesa
can safely be rebuilt against the new Mir.

I know it feels hacky, but this is the only working solution I have right now.

A possible alternative is to divide lp:mir into multiple projects (multiple debian source packages):
  client
  server
  shared
  demos
But that's much more painful than this, I think.

Any other suggestions?

[Daniel van Vugt (vanvugt)]

And before you ask:

No, the libmirclient.so.0 compatibility symlink does not get installed. It only exists in the build tree.

Yes, I have checked that all resulting binaries only refer to libmirclient.so.1 (objdump -p).

[PS Jenkins bot (ps-jenkins)]

PASSED: Continuous integration, rev:762
http://jenkins.qa.ubuntu.com/job/mir-ci/789/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/992
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/877
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/27
        deb: http://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/27/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-vm-ci-build/./distribution=quantal,flavor=amd64/465

Click here to trigger a rebuild:
http://s-jenkins:8080/job/mir-ci/789/rebuild

review: Approve (continuous-integration)

[Alan Griffiths (alan-griffiths)]

9 +# The version of libEGL.so.N installed on the build machine will often link
10 +# to an older version of libmirclient.so.N
...
19 + COMMAND ln -fs libmirclient.so.1 libmirclient.so.0

comment and code do not agree.

Otherwise it is splendidly brutal.

review: Needs Fixing

[Daniel van Vugt (vanvugt)]

Alan,

The comment and code are correct. Please review again.

[Robert Ancell (robert-ancell)]

Pure evil. Approved since it solves our immediate build issues, though we need to solve versioning and cyclic dependencies properly in the future.

review: Approve

[Chris Halse Rogers (raof)]

+1.

We should remove this once everything is rebuilt, and properly fix the cyclic dependency.

review: Approve

[Daniel van Vugt (vanvugt)]

We could make libEGL dlopen libmirclient in future. That would work :P

=== modified file 'src/client/CMakeLists.txt'
--- src/client/CMakeLists.txt	2013-06-18 03:27:39 +0000
+++ src/client/CMakeLists.txt	2013-06-21 09:56:28 +0000
@@ -73,6 +73,23 @@
   SOVERSION 1
 )
 
+#
+# The version of libEGL.so.N installed on the build machine will often link
+# to an older version of libmirclient.so.N than we're trying to build. But if
+# we allow EGL clients to link to both then they will depend on TWO different
+# sonames of mirclient and get linkage errors. This hack ensures that all EGL
+# mir clients in our source tree will only ever link to one version of
+# mirclient; that is the new one here.
+# It might sound nasty, but it's much nicer than having to maintain mirclient
+# and mirserver in different source packages.
+#
+add_custom_target(mirclient_compat_links
+  COMMAND ln -fs libmirclient.so.1 libmirclient.so.0
+  WORKING_DIRECTORY ${LIBRARY_OUTPUT_PATH}
+)
+# Ensure mirclient_compat_links exist before any dependents of mirclient
+add_dependencies(mirclient mirclient_compat_links)
+
 set(
   MIR_CLIENT_LIBRARIES
   ${Boost_LIBRARIES}