Windows DBus shared memory name depends on _DEBUG?

[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?

> One solution not to use the autolaunch procotol, another (probably
> better solution) is applying the following patches
>
> http://websvn.kde.org/*checkout*/trunk/kdesupport/emerge/portage/win32libs-sources/dbus-src/0001-Extended-autolaunch-protocol-with-scope-attribute.patch
>
> http://websvn.kde.org/*checkout*/trunk/kdesupport/emerge/portage/win32libs-sources/dbus-src/0002-Fixed-case-when-no-scope-attribute-is-used.patch
>
>
> They remove the release and debug distinction of the shared memory
> address and allows the user to specific a dedicated autolaunched bus by
> using the following bus address for the daemon and the client:
>
> autolaunch:scope=<term>
>
> where term is either
>
> 'install-path' to limit the bus to a specific install path or any other
> term for other specific use cases.
>
> With cmake this can be set on configure time by adding the following
> define:
>
> -DDBUS_SESSION_BUS_DEFAULT_ADDRESS:STRING=autolaunch:scope=<term>"

Those changes sound good to me - why aren't they part of dbus?

Thanks,

Thomas