> On May 12, 2016, 5:43 a.m., René J.V. Bertin wrote: > > CMakeLists.txt, lines 14-18 > > <https://git.reviewboard.kde.org/r/127896/diff/2/?file=464646#file464646line14> > > > > 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?!
yes, on OS X use of DBus is going to depend on whether or not Qt provides the QtDBus component. > On May 12, 2016, 5:43 a.m., René J.V. Bertin wrote: > > autotests/BackendsManager.cpp, lines 26-30 > > <https://git.reviewboard.kde.org/r/127896/diff/2/?file=464647#file464647line26> > > > > 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? i tested on linux - it did build fine > On May 12, 2016, 5:43 a.m., René J.V. Bertin wrote: > > autotests/BackendsManager.cpp, lines 56-60 > > <https://git.reviewboard.kde.org/r/127896/diff/2/?file=464647#file464647line56> > > > > Ditto, no risk of a build failure on systems where Qt does provide a > > DBus interface? no rosk. please read the 'testing' section of this review request > On May 12, 2016, 5:43 a.m., René J.V. Bertin wrote: > > src/CMakeLists.txt, line 2 > > <https://git.reviewboard.kde.org/r/127896/diff/2/?file=464650#file464650line2> > > > > Was this a redundant statement? yes, it was redundant. - Nick ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127896/#review95403 ----------------------------------------------------------- On May 12, 2016, 5: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, 5: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
