Cmake update patch for dbus master

[Romain Pokrzywka]

On Sunday 07 February 2010 05:50:11 Thiago Macieira wrote:
> Em Domingo 7. Fevereiro 2010, às 14.12.44, Ralf Habacker escreveu:
> > 2. There are use cases, in the kde context and may be others too, which
> > require to have different dbus session buses running for a single user.
> > There are several approaches available to reach this goal. Having a
> > special dbus daemon executable name may be one of these approaches. It
> > is worth to discuss the pro and cons of these approaches in a separate
> > thread.
>
> Why do you need to change the bus executable name?
>
> You can run the same daemon multiple times, can't you?

Correct. I think what he was referring to was the case where you want both builds types in the same output directory, 
then you'd have the release version overwriting the debug one. However I don't think that can really be an issue for 
KDE-Windows since we have separate build directories for each build type.

I was also thinking about kdeinit4 not being able to figure which one is the right one to autostart if they're both 
called dbus-daemon.exe, but here again it can't be an issue because there will only be one dbus-daemon in each 
KDEROOT/bin directory, and kdeinit4 won't look outside that folder afaik. (but that's maybe different when you're using 
the kdewin installer, I need to double check with Patrick Spendrin on that one)

More importantly, I think having different daemon names still fail to answer a critical issue: how to make the clients 
talk to the right daemon ? From what I see, both versions use the same tcp port, so the clients won't know which daemon 
they're connecting to anyway, regardless of their name. I haven't really looked much into that mechanism yet though, so 
maybe I'm missing something.


-- 
Romain Pokrzywka | romain at kdab.com | Certified Qt Software Engineer & Trainer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions