Merge lp:~raof/mir/pkgconfig-harder into lp:mir

[Chris Halse Rogers]

Tidy up mirserver.pc

We specify a lot of things that we don't need to, and failed to specify that we need protobuf.

Clean up mirserver.pc.

We've a lot of superfluous cruft in there. See the individual commit messages for details.

[PS Jenkins bot (ps-jenkins)]

PASSED: Continuous integration, rev:1826
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-ci/2324/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/1218
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-utopic-amd64-build/1224
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-utopic-touch/1207
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/846
        deb: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/846/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-armhf-ci/847
        deb: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-armhf-ci/847/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-utopic-armhf/142
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-utopic-armhf/142/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2324
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/11060

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

review: Approve (continuous-integration)

[Daniel van Vugt (vanvugt)]

(1) I think you will find this will break downstream projects like qtmir:
8 -Libs: -L@LIBDIR@ -lmirserver -lmirplatform -lmircommon

Using mirserver.pc needs to give downstream projects direct linkage to -lmircommon to get at some common symbols we expose via our server headers. Or are we actually much cleaner than I believe we are?

Needs information: testing with qtmir required. See also bug 1352757, which when resolved might answer my question automatically.

review: Needs Information

[Chris Halse Rogers (raof)]

I don't believe downstream projects need an explicit link to mircommon
as mirserver already pulls that in. To the experimentatron!

[Chris Halse Rogers (raof)]

I stand corrected. In fact, now that I think of it, we reasonably recently completed a transition in the linker to *not* consider indirect dependencies. Oops!

[Alan Griffiths (alan-griffiths)]

10 +Libs: -L@LIBDIR@ -lmirserver

Users also need -lmirplatform -lmircommon - as mentioned in your comments above.

~~~~

9 +Requires.private: protobuf >= 2.4.1

If users need access to protobuf headers should this be ".private"?

~~~~

I'm prepared to accept your views on the rpath - but do check downstream projects before landing it (as they tend to have broken dependency incantations on Mir).

review: Needs Fixing

[Alan Griffiths (alan-griffiths)]

> 9 +Requires.private: protobuf >= 2.4.1
>
> If users need access to protobuf headers should this be ".private"?

On closer examination I think this is actually unwanted. The "public" headers that "#include <google/protobuf/...>" are part of "PrivateProtobuf" - which we are not committing to supporting in the future. The headers are:

1. mir/frontend/message_processor.h
2. mir/frontend/protobuf_message_sender.h
3. mir/frontend/template_protobuf_message_processor.h

"PrivateProtobuf" was exposed as a *temporary* convenience for the Canonical downstreams to prototype adding IPC functions before proposing them to Mir proper (avoiding the need for them to put WIP code upstream). These downstream experiments will depend on protobuf directly.

The headers won't be removed for RTM but it should happen in the foreseeable future.

Unmerged revisions

1826. By Chris Halse Rogers on 2014-08-06

Drop bizzare rpath-link specification from mirserver.pc

We're not responsible for making sure that the end-user's system has a working
library path setup. If they install libmirserver outside ld.so's probing paths,
that's their (extremely weird) problem.

1825. By Chris Halse Rogers on 2014-08-06

Add protobuf dependency to mirserver.pc

Some of the server headers reference Protobuf headers, and use Protobuf
types, so users including server headers need to get Protobuf too.

1824. By Chris Halse Rogers on 2014-08-06

Remove superflous linkage in mirserver.pc

libmirserver.so already links against libmirplatform.so and libmircommon.so. There's
no need for users of libmirserver.so to explicitly link against mirserver's dependencies

=== modified file 'src/server/mirserver.pc.in'
--- src/server/mirserver.pc.in	2014-08-05 09:34:30 +0000
+++ src/server/mirserver.pc.in	2014-08-06 01:05:32 +0000
@@ -6,5 +6,6 @@
 Name: mirserver
 Description: Mir server library
 Version: @MIR_VERSION@
-Libs: -L@LIBDIR@ -lmirserver -lmirplatform -lmircommon -Wl,-rpath-link,@LIBDIR@
+Requires.private: protobuf >= 2.4.1
+Libs: -L@LIBDIR@ -lmirserver
 Cflags: -I@INCLUDEDIR@ -I@PLATFORM_INCLUDEDIR@ -I@COMMON_INCLUDEDIR@