Cmake update patch for dbus master

[Tor Lillqvist]

> The only way I see is to use installation path based shared memory segments.

I was first going to say that this sounds like a good idea, but then I
started thinking.

Consider this scenario: Several apps distributed by different people
use dbus. No app directly requires another, but there is some useful
information oner app can send on the bus to another app if present.
All apps come bundled with dbus, and all install the dbus daemon and
client library under their own installation folder. This is what one
should do, right?

So if the name of the shared memory segment is based on where the dbus
client library (DLL) is installed, these apps will be using different
session buses, and won't be able to talk to the others.

So does you suggestion implicitly require that people who build
installers for Windows apps that use dbus and that *want* the session
bus instance their app uses is able to talk to whatever other apps
there are present agree on a way to install (possibly update a
previous installation of) a shared copy of dbus? I think that will be
quite hard to achieve. Some people like MSI-based installer
technology, some might not like it but feel it is required for
"enterprise readiness", others won't touch it with a stick and prefer
NSIS, others prefer InnoSetup, etc etc.

--tml