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 couldn't. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
