Re: Fetching googlemock

2014-12-15 Thread Ben Cooksley
On Mon, Dec 15, 2014 at 1:02 AM, Myriam Schweingruber myr...@kde.org wrote:
 Hi all,

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.

 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

The CI system doesn't do anything special. It has a build of GMock
which it creates itself (with no special options) and which Amarok is
asked to use.
I've no idea if tests were disabled because they failed on the CI
system though i'm afraid.


 Regards,
 Myriam

Cheers,
Ben


 --
 Proud member of the Amarok and KDE Community
 Protect your freedom and join the Fellowship of FSFE:
 http://www.fsfe.org
 Please don't send me proprietary file formats,
 use ISO standard ODF instead (ISO/IEC 26300)
___
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel


Re: Fetching googlemock

2014-12-15 Thread Dan Meltzer
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


Re: Fetching googlemock

2014-12-14 Thread Myriam Schweingruber
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.

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

Regards,
Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)
___
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel


Re: Fetching googlemock

2014-12-14 Thread Konrad Zemek
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


Re: Fetching googlemock

2014-12-14 Thread Matěj Laitl
On 14. 12. 2014 Konrad Zemek wrote:
  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.

Thinking about it more, this should work. Initially I was thinking about how 
distros ship packages, but this should not touch binary distros at all.

How big is tarballed gtest + gmock? Can we just embed them in our release 
tarballs? Else we can create something like amarok-testlibs-$version.tar.bz2, 
but that would be more work and effort.

Matěj
___
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel


Re: Fetching googlemock

2014-12-14 Thread Konrad Zemek
2014-12-14 13:38 GMT+01:00 Matěj Laitl ma...@laitl.cz:
 On 14. 12. 2014 Konrad Zemek wrote:
  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.

 Thinking about it more, this should work. Initially I was thinking about how
 distros ship packages, but this should not touch binary distros at all.

 How big is tarballed gtest + gmock? Can we just embed them in our release
 tarballs? Else we can create something like amarok-testlibs-$version.tar.bz2,
 but that would be more work and effort.

tarred and bzipped, the repos take 588KB of space (tbz2 of the whole
Amarok source is 158MB). I can look into shallow clones if needed.

Konrad
___
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel


Re: Fetching googlemock

2014-12-14 Thread Matěj Laitl
On 14. 12. 2014 Konrad Zemek wrote:
 Matěj Laitl wrote:
  How big is tarballed gtest + gmock? Can we just embed them in our release
  tarballs? Else we can create something like
  amarok-testlibs-$version.tar.bz2, but that would be more work and effort.
 
 tarred and bzipped, the repos take 588KB of space (tbz2 of the whole
 Amarok source is 158MB). I can look into shallow clones if needed.

Easy then, we can bundle gtest+gmock in Amarok release tarballs.

Note that we don't release repository, just the sources [1], so shallow clones 
won't affect it -- last Amarok release had ~ 38 MB. (but that includes 
translations and handbooks) So size of gtest+gmock will be even smaller.

So please go ahead! :) Please have a look if release_scripts/RELEASE_HOWTO 
and/or amarok2.rb in releaseme.git [2] should be updated. Ideally if you try 
to make an Amarok release tarball and check whether it looks as expected.

Thanks,
Matěj

[1] 
http://download.kde.org/stable/amarok/2.8.0/src/amarok-2.8.0.tar.bz2.mirrorlist
[2] http://quickgit.kde.org/?p=releaseme.gita=blobf=amarok2.rb
___
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel


Re: Fetching googlemock

2014-12-14 Thread Konrad Zemek
2014-12-14 16:07 GMT+01:00 Matěj Laitl ma...@laitl.cz:
 On 14. 12. 2014 Konrad Zemek wrote:
 Matěj Laitl wrote:
  How big is tarballed gtest + gmock? Can we just embed them in our release
  tarballs? Else we can create something like
  amarok-testlibs-$version.tar.bz2, but that would be more work and effort.

 tarred and bzipped, the repos take 588KB of space (tbz2 of the whole
 Amarok source is 158MB). I can look into shallow clones if needed.

 Easy then, we can bundle gtest+gmock in Amarok release tarballs.

 Note that we don't release repository, just the sources [1], so shallow clones
 won't affect it -- last Amarok release had ~ 38 MB. (but that includes
 translations and handbooks) So size of gtest+gmock will be even smaller.

 So please go ahead! :) Please have a look if release_scripts/RELEASE_HOWTO
 and/or amarok2.rb in releaseme.git [2] should be updated. Ideally if you try
 to make an Amarok release tarball and check whether it looks as expected.

Thanks; I had to make some changes to amarok2.rb and will put up a
review of that as well. I've tested the resulting tarball and it's
working beautifully. :)

There's still the issue of repositories; maybe we could leave my repos
in the meantime and change the references later on (or during the
review)?

Konrad
___
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel


Re: Fetching googlemock

2014-12-13 Thread Matěj Laitl
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.

 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).

Regards,
Matěj
___
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel