----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127896/#review95403 -----------------------------------------------------------
Forgive me if I'd like to be certain that this isn't disabling DBus altogether on OS X! CMakeLists.txt (lines 14 - 18) <https://git.reviewboard.kde.org/r/127896/#comment64679> Am I right that on OS X use of DBus is going to depend on whether or not Qt provides the QtDBus component? If so, shouldn't this be done on MS Windows too? If that's *not* the right interpretation: PLEASE introduce proper option variables for this kind of thing, for instance in ECM. Consider the overal picture; is this only about DBus or is this ultimately about building standalone app bundles? In other words, would it be possible to name that option variable appropriately to allow it to act as a switch for other, related build options? This is all the more appropriate (and *polite*) if this is a convenience change for HomeBrew - why would such a change oblige other packaging/distribution systems to add and maintain unknown amounts of additional patches to undo it?! autotests/BackendsManager.cpp (lines 26 - 30) <https://git.reviewboard.kde.org/r/127896/#comment64680> Again, double-checking: Is QT_NO_DBUS really going to be defined if the cmake system didn't do a `find_package(Qt5 ... DBus)`? IOW, is this change not going to introduce a build failure on systems where Qt does provide a DBus interface? autotests/BackendsManager.cpp (lines 56 - 60) <https://git.reviewboard.kde.org/r/127896/#comment64681> Ditto, no risk of a build failure on systems where Qt does provide a DBus interface? autotests/HelperTest.cpp (lines 27 - 31) <https://git.reviewboard.kde.org/r/127896/#comment64682> Ditto, no risk of a build failure on systems where Qt does provide a DBus interface? autotests/HelperTest.cpp (lines 106 - 110) <https://git.reviewboard.kde.org/r/127896/#comment64683> Ditto, no risk of a build failure on systems where Qt does provide a DBus interface? src/CMakeLists.txt <https://git.reviewboard.kde.org/r/127896/#comment64684> Was this a redundant statement? - René J.V. Bertin On May 12, 2016, 7:16 a.m., Nick Shaforostoff wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127896/ > ----------------------------------------------------------- > > (Updated May 12, 2016, 7:16 a.m.) > > > Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, > and Martin Gräßlin. > > > Repository: kauth > > > Description > ------- > > this is the first patch to make kde frameworks build (and then work) without > dbus. > > this will allow homebrew users use precompiled vanilla Qt to build kde apps > on osx. as dbus is not a common service in osx world, kde apps on osx should > use native means for interprocess communication instead -- this will make > them better citizens in osx ecosystem. > > > Diffs > ----- > > CMakeLists.txt 48dc2d9 > autotests/BackendsManager.cpp 59675b3 > autotests/CMakeLists.txt b53d760 > autotests/HelperTest.cpp 8050a06 > src/CMakeLists.txt 1b6930d > src/ConfigureChecks.cmake d46761a > > Diff: https://git.reviewboard.kde.org/r/127896/diff/ > > > Testing > ------- > > compiles fine on osx, compiles fine on linux, tests on linux still pass. > > > Thanks, > > Nick Shaforostoff > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
