Re: qca-qt5 (qt5 branch) merge into qca (master branch)
QCA's qt5 branch has now been merged back into master. master now behaves like qt5 did. If qt5 is found libqca-qt5 is built, if it isn't found qt4 is a requirement and libqca will be built. You can override this behavior by using the cmake option QT4_BUILD. Going to prep a tarball shortly. HS
Re: qca-qt5 (qt5 branch) merge into qca (master branch)
On Thursday 24 of September 2015 11:02:10 Harald Sitter wrote: > ahoy ahoy > > qca-qt5 as a "thing" is a build time switch on the same source as qca > (qt4). so, it is the same source base but depending on how you run > cmake you either get the qt5 or the qt4 build. > > originally various adjustments had to be made to qca-qt5 to make it > work reliably without conflicting with qca (qt4), there was however a > very long discussion on whether or not that is the right thing to do > which eventually ended in the maintainer stepping down [anyone wanna > maintain qca? it's like phonon but for crypto :)]. at the time qca-qt5 > as a tarball was released which had the changes and could co-exist > with the regular qca tarball. > > now, since qca essentially has no lead authority we could do what was > the original intention here. i.e. make the qca source base build two > distinct libraries for qt4 and qt5 that do not conflict in any form or > fashion. this would be a simple `git merge qt5` and then we can > release a qca tarball that replaces the old qca-qt5 tarball. > > Q: any objections to merging qca's qt5 branch into master and > replacing the qt5 tarball with a new release that supports both qt4 > and qt5? > + 1, we added qca as dependency for plasma-nm and to be able to build it you need the latest fix I pushed to qca thus new release of qca before Plasma 5.5.0 release is needed. Regards, Jan -- Jan Grulich Software Engineer, Desktop team Red Hat Czech
Re: qca-qt5 (qt5 branch) merge into qca (master branch)
On Thu, Sep 24, 2015 at 11:02 AM, Harald Sitter wrote: > ahoy ahoy > > qca-qt5 as a "thing" is a build time switch on the same source as qca > (qt4). so, it is the same source base but depending on how you run > cmake you either get the qt5 or the qt4 build. > > originally various adjustments had to be made to qca-qt5 to make it > work reliably without conflicting with qca (qt4), there was however a > very long discussion on whether or not that is the right thing to do > which eventually ended in the maintainer stepping down [anyone wanna > maintain qca? it's like phonon but for crypto :)]. at the time qca-qt5 > as a tarball was released which had the changes and could co-exist > with the regular qca tarball. > > now, since qca essentially has no lead authority we could do what was > the original intention here. i.e. make the qca source base build two > distinct libraries for qt4 and qt5 that do not conflict in any form or > fashion. this would be a simple `git merge qt5` and then we can > release a qca tarball that replaces the old qca-qt5 tarball. > > Q: any objections to merging qca's qt5 branch into master and > replacing the qt5 tarball with a new release that supports both qt4 > and qt5? > > HS It's the only branch I've been testing. I'd love to be able to use master instead. Aleix
qca-qt5 (qt5 branch) merge into qca (master branch)
ahoy ahoy qca-qt5 as a "thing" is a build time switch on the same source as qca (qt4). so, it is the same source base but depending on how you run cmake you either get the qt5 or the qt4 build. originally various adjustments had to be made to qca-qt5 to make it work reliably without conflicting with qca (qt4), there was however a very long discussion on whether or not that is the right thing to do which eventually ended in the maintainer stepping down [anyone wanna maintain qca? it's like phonon but for crypto :)]. at the time qca-qt5 as a tarball was released which had the changes and could co-exist with the regular qca tarball. now, since qca essentially has no lead authority we could do what was the original intention here. i.e. make the qca source base build two distinct libraries for qt4 and qt5 that do not conflict in any form or fashion. this would be a simple `git merge qt5` and then we can release a qca tarball that replaces the old qca-qt5 tarball. Q: any objections to merging qca's qt5 branch into master and replacing the qt5 tarball with a new release that supports both qt4 and qt5? HS
