Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
On Thursday 11 December 2014 08:41:22 Kurt Pattyn wrote: On 11 Dec 2014, at 08:30, Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday 10 December 2014 17:42:06 Thiago Macieira wrote: Explanation: * runtime: dynamically open libdbus-1 at runtime * linked: link to libdbus-1 * configure1: check at configure time if libdbus-1 is present in the system and then enable runtime mode * configure2: check at configure time if libdbus-1 is present in the system; if it is, enable linked mode, otherwise runtime In other words: starting with Qt 5.4.1, QtDBus will be enabled FOR ALL BUILDS. Clarifying after question on IRC: will be enabled by default for all builds on all OS. Unless you pass -no-dbus, of course. Will it be enabled using configure1 or configure2? As of 5.4.1. In 5.4.0, it tries to find the headers before deciding that it doesn't need them. -- 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
Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
From: development-bounces+alexander.blasche=theqtcompany@qt-project.org development-bounces+alexander.blasche=theqtcompany@qt-project.org on behalf of Thiago Macieira thiago.macie...@intel.com Clarifying after question on IRC: will be enabled by default for all builds on all OS. Unless you pass -no-dbus, of course. What's the runtime call that let's me determine what the state of the dbus union is on the system? 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 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. - 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? Personally, I think it is rather useless to enable QtDBus on for example Windows. Yes, its better cross-platform programming and there are some esoteric guys/projects who use dbus at this stage on Windows. However the default setting to enable it for the esoteric use case means you ship tons more code for nothing. Alternatives might have been to only enable it when specifically requested only (aka change your configure2 option to disabled on windows if no dbus option passed) or even compile the lib against some no-op code (which would satisfy the true cross platform development use case). I guess you might argue that QtDBus is not that large but without more strict qmake changes you may create more code to be shipped in other modules/projects too. What were your reasons/motivation? -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
On 11 Dec 2014, at 02:42, Thiago Macieira thiago.macie...@intel.com wrote: Dear all My well-intentioned changes to unbreak the building of the OS X builds for 5.4.0 have apparently had unexpected consequences. After reviewing the situation, I've created https://codereview.qt-project.org/101843 to fix the issues (note: updates for Windows pending). Once that one is in 5.4 and merged to 5.5, I'll submit another fix for 5.5 changing the configure behaviour. configure option: Qt 5.4.0Qt 5.4.1 Qt 5.5† none configure1 runtime configure2 -dbus runtime runtime configure2 -dbus-linked linked linked linked --dbus=runtimeruntime runtime runtime -no-dbus disableddisabled disabled Explanation: * runtime: dynamically open libdbus-1 at runtime * linked: link to libdbus-1 * configure1: check at configure time if libdbus-1 is present in the system and then enable runtime mode * configure2: check at configure time if libdbus-1 is present in the system; if it is, enable linked mode, otherwise runtime In other words: starting with Qt 5.4.1, QtDBus will be enabled FOR ALL BUILDS. The library is safe enough in dynamic mode that it will simply say that it could not connect to the bus or peer, so it should not be a problem to have it present. †: unless we get the rewrite to drop libdbus-1 requirements in time for 5.5, but I think it's unlikely. Maybe Qt 5.6. I’m wondering, do we want to keep the “none” behavior to “runtime” for OS X? libdbus-1 (and pkg-config) may be installed for two reasons: 1) As a dependency for Qt. 2) As a dependency for something else (some other homebrew package, or an unrelated dev project). I think 2) is more common, and that a default Qt build should use stock OS X only. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
On Thursday 11 December 2014 14:14:06 Morten Johan Sørvig wrote: I’m wondering, do we want to keep the “none” behavior to “runtime” for OS X? libdbus-1 (and pkg-config) may be installed for two reasons: 1) As a dependency for Qt. 2) As a dependency for something else (some other homebrew package, or an unrelated dev project). I think 2) is more common, and that a default Qt build should use stock OS X only. Task QTBUG-14131 asks to make runtime the default on OS X but linked the default everywhere else. That's how I started with https://codereview.qt-project.org/100573 However, I later decided to remove the OS X-specific check. Why have it in the first place? The reason why we concluded in that task to ask for the runtime as the default for OS X was because we required the libdbus-1 headers. Now we don't: we can compile QtDBus without libdbus-1, which is the default situation in OS X. In any case, I just think we shouldn't special-case it. -- 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
Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
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
Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
Blasche Alexander wrote: Personally, I think it is rather useless to enable QtDBus on for example Windows. Yes, its better cross-platform programming and there are some esoteric guys/projects who use dbus at this stage on Windows. The kdewin (KDE on Windows; in particular, ports of KDE applications to Windows) project uses it. I don't think kdewin qualifies as esoteric. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
On Friday 12 December 2014 02:36:11 Kevin Kofler wrote: Blasche Alexander wrote: Personally, I think it is rather useless to enable QtDBus on for example Windows. Yes, its better cross-platform programming and there are some esoteric guys/projects who use dbus at this stage on Windows. The kdewin (KDE on Windows; in particular, ports of KDE applications to Windows) project uses it. I don't think kdewin qualifies as esoteric. Turns out that KDE on Windows never even attempted to run the QtDBus unit tests on Windows. I know that because they simply didn't run on Windows or even compile there. I've just pushed a sequence of fixes (101957 through 101967) that make the tests work on Windows. -- 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
Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
On Wednesday 10 December 2014 17:42:06 Thiago Macieira wrote: Explanation: * runtime: dynamically open libdbus-1 at runtime * linked: link to libdbus-1 * configure1: check at configure time if libdbus-1 is present in the system and then enable runtime mode * configure2: check at configure time if libdbus-1 is present in the system; if it is, enable linked mode, otherwise runtime In other words: starting with Qt 5.4.1, QtDBus will be enabled FOR ALL BUILDS. Clarifying after question on IRC: will be enabled by default for all builds on all OS. Unless you pass -no-dbus, of course. -- 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
Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
On 11 Dec 2014, at 08:30, Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday 10 December 2014 17:42:06 Thiago Macieira wrote: Explanation: * runtime: dynamically open libdbus-1 at runtime * linked: link to libdbus-1 * configure1: check at configure time if libdbus-1 is present in the system and then enable runtime mode * configure2: check at configure time if libdbus-1 is present in the system; if it is, enable linked mode, otherwise runtime In other words: starting with Qt 5.4.1, QtDBus will be enabled FOR ALL BUILDS. Clarifying after question on IRC: will be enabled by default for all builds on all OS. Unless you pass -no-dbus, of course. Will it be enabled using configure1 or configure2? -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
