On Sun, Dec 14, 2014 at 7:21 AM, Konrad Zemek <konrad.ze...@gmail.com> wrote: > > Hey, > > 2014-12-14 13:02 GMT+01:00 Myriam Schweingruber <myr...@kde.org>: > > Hi all, > > > > > > On Sat, Dec 13, 2014 at 11:07 PM, Matěj Laitl <ma...@laitl.cz> wrote: > >> > >> On 13. 12. 2014 Konrad Zemek wrote: > >> > gmock sources are still not packaged by distributions, and compiling > >> > Amarok with tests on is still troublesome (I still use a cmake-gui > >> > based approach where I manually set paths to my pre-compiled gmock > >> > lib, as I outlined in an email some months ago). > >> > > >> > I solved the problem through the use of submodules and commited the > >> > change to my personal scratch repo [1]. (...) > >> > > >> > If you find my approach agreeable, I will be happy to put it on > >> > reviewboard. > >> > >> Git submodule approach looks promising, however I have some concerns: > >> a) this makes test depend on 'your' github repositories; we cannot > >> guarantee > >> they won't go away etc. > >> b) this makes testing Amarok require internet connection, at least > >> initially; > >> this of shipping entire sources to build a distribution package etc. > >> c) circumvents source file checksumming etc. that many distributions do > >> to > >> enhance security > >> d) is it legally okay to redistribute googlemock, googletest? Using a > git > >> repo, shipping a tarball? > >> > >> Still, I like the idea. a) seems easily fixable b), c) seems fixable by > >> tweaking > >> the way we create Amarok tarballs. > >> > > > > I guess a) can be easily fixed if this goes to our git repo. > > as for d) since googlemock is Free Software (New BSD 3 clause license, > see > > also https://code.google.com/p/googlemock/), this shouldn't be a > problem. > > As for b) and c), I was imagining that `git submodule update --init` > would become a standard step to fetch sources for creating a tarball > or building tests. The auto-fetch is there just for convenience. > > > > > Can we please make a release soon, Matěj? There is one release blocker > bug > > which I still can reproduce and which falls in your speciality, but else > we > > are good for 2.9 since quite some time :) > > > > > >> > >> > By the way, I noticed that importer tests are now guarded with > >> > 'if(LINUX)' macro. There is no 'LINUX' platform in CMake, though, so > >> > these tests are effectively disabled everywhere. I guess there were > >> > some problems on non-linux systems? > >> > >> Looks like a bug to me, feel free to investigate and fix, the test > should > >> run > >> at least on Linux platforms (best if they are run everywhere). > >> > > As for the LINUX tests: since the tests also run on Jenkins, maybe that > is > > the reason? subscribing Ben > > Also Patrick can tell if the problem lies with building tests on Windows, > > subscribing Patrick > > Here's the commit log for the change: > commit 726639b840e2a7a08fe68f04170f06b25a713c08 > Author: Daniel Meltzer <parallelgrapefr...@gmail.com> > Date: Fri May 16 20:09:17 2014 -0400 > Don't build the importer tests on windows either. Same issue as mac > with linking to a plugin > > Seems that there've been problems with linking tests on Windows and > OS-X. For now I'll just change the line to `if( ${CMAKE_SYSTEM_NAME} > MATCHES "Linux" )`. >
Yeah, we build them as plugins, and then link to the plugins. Not possible on windows/os x. > > Konrad > _______________________________________________ > Amarok-devel mailing list > Amarok-devel@kde.org > https://mail.kde.org/mailman/listinfo/amarok-devel >
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
