Cmake update patch for dbus master

[Ralf Habacker]

Thiago Macieira schrieb:
> Em Segunda-feira 8. Fevereiro 2010, às 11.58.35, Ralf Habacker escreveu:
>   
>>> Sounds like that #ifdef shouldn't be there.
>>>
>>> The wire protocol is the same. There's no reason for a debug-library not
>>> to talk to a release daemon. And also why a debug library cannot talk to
>>> a release library on another program.
>>>       
>> You didn't get the point.
>>
>> This stuff is used for autodetecting the session bus address.
>> Dbus-daemon saves its real used bus address into a shared memory
>> segment, which will be fetched from the client to connect to the proper
>> daemon when not using environment variables (which is the default case
>> on windows) On windows a debug build daemon stores its address in a
>> different shared memory segment as the release daemon.
>>     
>
> I did understand that.
>
> I'm arguing that it should be the same shared memory segment.
>
> 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. "


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.
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.

Technical is is possible to run one dbus-daemon for all releases, but 
which klauncher/kded  will then be started ? 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.

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

The dbus-daemon only session.conf isn't accessable by clients directly, 
so the dbus client library uses a well kown shared memory area to 
retrieve dbus session address information. At now a debug/release mode 
separation is implemented in the dbus client library, by using the debug 
dbus daemon we have a separate dbus session.

But how to separate installations of the same build type ?

The only way I see is to use installation path based shared memory 
segments. Because a debug release will be installed into a separate 
directory, installation based shared memory segments will also support 
release/debug mode distinction.

The client library should have additional code to check the presence of 
installation path based shared memory segments first and if not 
available the generic ono.

On dbus-daemon side an additional config option should be added to 
enable this mode. If enabled dbus-daemon should create the appropriate 
shared memory segment for client access.

Any comments ?

Regards
 Ralf