Windows DBus shared memory name depends on _DEBUG?

[David Zeuthen]

Hi,

On Wed, Sep 22, 2010 at 5:57 AM, Ralf Habacker <ralf.habacker at freenet.de> wrote:
> 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.
>
> 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>"

Any chance you can put all this in the D-Bus specification so other
D-Bus implementations have a chance of interoperating with libdbus-1
implementations? It really needs to be there (and I'd like it to be
there so I can add support to GDBus) - doesn't have to be super long,
just something about how to find the session bus address from a memory
segment with the name "DBusDaemonAddressInfo" or something. FWIW, I'd
be more than happy to review your spec changes.

Not to pick on you personally, but it's pretty bad that we're
releasing libdbus-1 code that relies on behavior not in the spec.

     David