<div dir="ltr">Hi all,<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 13, 2014 at 11:07 PM, Matěj Laitl <span dir="ltr"><<a href="mailto:matej@laitl.cz" target="_blank">matej@laitl.cz</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 13. 12. 2014 Konrad Zemek wrote:<br>
> gmock sources are still not packaged by distributions, and compiling<br>
> Amarok with tests on is still troublesome (I still use a cmake-gui<br>
> based approach where I manually set paths to my pre-compiled gmock<br>
> lib, as I outlined in an email some months ago).<br>
><br>
> I solved the problem through the use of submodules and commited the<br>
</span>> change to my personal scratch repo [1]. (...)<br>
<span class="">><br>
> If you find my approach agreeable, I will be happy to put it on reviewboard.<br>
<br>
</span>Git submodule approach looks promising, however I have some concerns:<br>
 a) this makes test depend on 'your' github repositories; we cannot guarantee<br>
they won't go away etc.<br>
 b) this makes testing Amarok require internet connection, at least initially;<br>
this of shipping entire sources to build a distribution package etc.<br>
 c) circumvents source file checksumming etc. that many distributions do to<br>
enhance security<br>
 d) is it legally okay to redistribute googlemock, googletest? Using a git<br>
repo, shipping a tarball?<br>
<br>
Still, I like the idea. a) seems easily fixable b), c) seems fixable by tweaking<br>
the way we create Amarok tarballs.<br>
<span class=""><br></span></blockquote><div><br class="">I guess a) can be easily fixed if this goes to our git repo.</div><div>as for d) since googlemock is Free Software (New BSD 3 clause license, see also <a href="https://code.google.com/p/googlemock/">https://code.google.com/p/googlemock/</a>), this shouldn't be a problem. </div><div><br></div><div>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 :)</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> By the way, I noticed that importer tests are now guarded with<br>
> 'if(LINUX)' macro. There is no 'LINUX' platform in CMake, though, so<br>
> these tests are effectively disabled everywhere. I guess there were<br>
> some problems on non-linux systems?<br>
<br>
</span>Looks like a bug to me, feel free to investigate and fix, the test should run<br>
at least on Linux platforms (best if they are run everywhere).<br><br></blockquote><div>As for the LINUX tests: since the tests also run on Jenkins, maybe that is the reason? subscribing Ben</div><div>Also Patrick can tell if the problem lies with building tests on Windows, subscribing Patrick</div><div><br></div><div>Regards,</div><div>Myriam</div></div><div><br></div>-- <br><div class="gmail_signature">Proud member of the Amarok and KDE Community<br>Protect your freedom and join the Fellowship of FSFE:<br><a href="http://www.fsfe.org" target="_blank">http://www.fsfe.org</a><br>Please don't send me proprietary file formats,<br>use ISO standard ODF instead (ISO/IEC 26300)</div>
</div></div>