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" )`. Konrad _______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel