On Thursday 11 December 2014 08:40:20 Blasche Alexander wrote:
> So far there are two cases:
> 1.) no dbus (nice qmake check to cut for Windows, Android and some other
> platforms) 
> 2.) dbus available but no daemon or permission issues
> (QDbusConnection::connectToBus(...).isConnected()) 
> 3.) all working and enabled

Off by one error?

Actually, it's a little more complex than that. D-Bus is useful on Windows 
too, just like on OS X, which was the cause of the changes. It just happens 
that we built QtDBus for OS X but not for Windows. And as I learned yesterday, 
no one has EVER built the QtDBus unit tests on Windows.

By default, on OS X with just our build, you'll get a slightly different 
scenario you didn't list: QtDBus available but no libdbus-1. However, if 
libdbus-1 isn't present, the daemon most likely isn't either, so we could say 
it's case #2.

> Consequences of eventual 5.5 changes:
> - Now I cannot use point 1. above anymore to compile dbus backends out on
> platforms where DBus is useless anyway. That's doable by emulating your
> platform specific enabler in my own modules of course. I guess this is just
> convenience which I lost.

Correct. I expect you to know where D-Bus isn't useful to you, as opposed to 
having me force that upon you. There are legitimate reasons to use D-Bus on OS 
X and Windows, even on Android. So I'm just giving you the tools, you choose 
what use to make of them.

> - Case 2 above is even further overloaded. How do I distinguish the
> no-daemon case from permission issues from dlopen failures. Any new API
> calls for that? This is especially important when you don't want to do the
> "compile dbus out on win" checks in qmake. Do I have to duplicate your
> dlopen() attempt to figure that out? How about a
> "QDBusConnection::platformSupportsDbus()" call?

It's not more further overloaded than it already is. Like I said above for 
OS X, your case here was already present. No one has required this check in 
the 7 years since we began dlopen'ing libdbus-1.

> What were your reasons/motivation?

Fixing Qt 5.4 after the last-minute changes for 5.4.0 that were introduced to 
unbreak the build on OS X. This is not a policy change. It just so happens 
that we now *can* build QtDBus on all of those OS, so we will. Previously, we 

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

Development mailing list

Reply via email to