Windows DBus shared memory name depends on _DEBUG?

[Ralf Habacker]

  Am 23.09.2010 14:35, schrieb Thomas Sondergaard:
> On 22-09-2010 16:39, Ralf Habacker wrote:
>> Am 22.09.2010 12:58, schrieb Thomas Sondergaard:
>>> On 22-09-2010 11:57, Ralf Habacker wrote:
>>>> Am 22.09.2010 11:06, schrieb Thomas Sondergaard:
>>>> This is guaranted by the autolaunch protocol. When using autolaunch
>>>> procotol in session bus config, dbus-daemon server automatically 
>>>> select
>>>> a free tcp port on localhost and saves this address in the related
>>>> shared memory segment. If the dbus client is configured using the
>>>> autolaunch protocol (which is the default on configure time) it 
>>>> fetches
>>>> the recent session dbus address from the related shared memory 
>>>> address.
>>>> Now debug and release builds could run independent dbus daemons.
>>>
>>> I'm a little confused by your answer. Let me ask a little differently:
>>> Wouldn't it be best if debug and release builds using the default
>>> autolaunch protocol would connect to the same bus?
>> I think this depends on the use case. In the KDE on windows context -
>> where this implementation came from - this "feature" has been used to
>> run a release build for daily work and an independent debug build. KDE
>> uses dbus-daemon to start further applications and kioslaves. If there
>> would only one daemon, debug applications would start slaves from
>> release builds and vice versus, depending on which daemon has been
>> started first. This makes debugging much harder.
>> Because of this limitations the mentioned patch is used for KDE as 
>> default.
>
> It is usual for debug builds to link debug libraries on windows and I 
> think the use case should be that this works fine mixed with a release 
> build of dbus-daemon. 
> It would not be much trouble for KDE hackers to configure their build 
> of the dbus to use a different name for the autolaunch shared memory 
> segment - especially if it was made a cmake build option, a la 
> -DDBUS_AUTOLAUNCH_SHM_NAME=flimsebimse.
There are different use case required for different people. The current 
implemation makes sense for some people, while your use case makes also 
sense for other people. The conclusion is to make the autolaunch feature 
customizable in a generic way, which is provided by the mentioned patch 
which provides a controlled way for setting the shared memory address.

If there are no more objectivies I will apply these patches in the next 
days along with the autolaunch spec update.

Regards
  Ralf