Cmake update patch for dbus master

Thiago Macieira thiago at kde.org
Tue Feb 9 06:58:53 PST 2010


Em Terça-feira 9. Fevereiro 2010, às 09.29.43, Ralf Habacker escreveu:
> > Since the wire protocol is the same, there's no reason why a debug-mode
> > application should have to link to a debug-mode daemon.
> 
> I understand - but how to ensure then the use case Romain (and others)
> talked about:
> 
> "... require to have different dbus session buses running for a single
> user.
> 
> "Definitely. That's something that could be useful not only for the debug
> vs. release case, but also for different versions of KDE apps running in
> parallel. For example, I usually have a stable KDE-Windows build for my
> common apps, then I have an enterprise4 branch build for Kontact, and I
> also keep a trunk build for testing and development. Currently I have to
> kill all processes (including dbus-daemon) everytime I need to switch
> between those, which is a PITA. "

I'd say the answer should be "Use the same technique as on Unix"

If you require different busses, you just set a different environment variable 
(DBUS_SESSION_BUS_ADDRESS). It will be inherited by all processes in that 
session.

What's more, I don't see what D-Bus busses have to do with different KDE 
builds. You can use the same, running dbus-daemon.exe with different KDE 
builds. Kill all KDE processes from one build, then start them again from 
another.

> On command line one can set easily an environment variables to instruct
> the dbus client where to contact the dbus daemon, but how to ensure this
> for KDE releases on windows.

You don't, same as on Unix.

If there's no bus running, it will use the shared memory segment to get the 
address, starting the daemon if there's no bus running. (Same as on Unix).

If the DBUS_SESSION_BUS_ADDRESS variable is set, use that. (Same as on Unix)

> dbus is not part of the windows operating system and is not started on
> user session startup as on linux - dbus is a part of  every KDE release
> may it be stable/unstable/nightly or local development.
> KDE applications are started mostly from the start menu, so environment
> settings like DBUS_SESSION_BUS_ADDRESS will not work here or are not
> uniq for one dbus.

Same as on Unix (if that's a Unix where dbus-daemon isn't started, which still 
exists).

> Technical is is possible to run one dbus-daemon for all releases, but
> which klauncher/kded  will then be started ?

Those are not started by dbus-daemon. There's code in kdelibs/kdecore to start 
kdeinit4, klauncher, kded4, etc. That's where the path is determined.

In theory, it would be possible to run two sets of those applications on the 
same computer, by the same user, if they were in separate buses. But at least 
on Unix, kdeinit4 also creates a socket which is keyed to the X display, so it 
wouldn't work -- on Windows, it may.

> I guess from the release
> from which I started the first application. Assuming this release is my
> daily work release - as Romain said, when I need to restart the
> development release I have to restart my stable release too - this is bad.

See above.

And even if that were the case, you could override by starting those 
applications yourself.

> The conclusion is there must be a way to separate a dbus-daemon to a
> specific release. But how to implement such a feature ?

I disagree that there is such a need.

[snip the rest]
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20100209/ade914f4/attachment.pgp 


More information about the dbus mailing list