Fetching googlemock

[Konrad Zemek]

Hey,

2014-12-14 13:02 GMT+01:00 Myriam Schweingruber <myriam at kde.org>:
> Hi all,
>
>
> On Sat, Dec 13, 2014 at 11:07 PM, Matěj Laitl <matej at 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 <parallelgrapefruit at 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