Fetching googlemock

[Dan Meltzer]

On Sun, Dec 14, 2014 at 7:21 AM, Konrad Zemek <konrad.zemek at gmail.com>
wrote:
>
> 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" )`.
>

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 at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20141215/5f2edce0/attachment.html>