Local copy of gtest
Summary: If we want to run tests in the PPA, we probably need to include a copy of gtest source in our repo. Any objections?
Hi All,
Are there any objections to bundling a copy of the Google test framework source code into our trunk repo? At the moment, we provide the download-gtest.sh script for grabbing the gtest source from upstream. However, this presents a couple of issues:
1. It's obviously dependent on a network connection to the upstream packages being available
2. We can't run the wget download in the Ubuntu builder
Can I suggest that we simply adopt a copy of the gtest source? Are there any good reasons (e.g. licensing) not to do this? I'm generally not keen on repo bloat but AFAIU it's generally considered good practice to bundle test frameworks with project source code.
AV
OK, looking into this a little further, it seems that there is a Debian package libgtest-dev, which contains the Googletest source code, and a google-mock package, which provides the gmock binaries. It may be possible to adapt the CMake builds to allow us to use these packages. I'll look into it!
AV
On 7 June 2016 at 18:11, Alex Valavanis <valavanisalex@...400...> wrote:
Summary: If we want to run tests in the PPA, we probably need to include a copy of gtest source in our repo. Any objections?
Hi All,
Are there any objections to bundling a copy of the Google test framework source code into our trunk repo? At the moment, we provide the download-gtest.sh script for grabbing the gtest source from upstream. However, this presents a couple of issues:
- It's obviously dependent on a network connection to the upstream
packages being available
- We can't run the wget download in the Ubuntu builder
Can I suggest that we simply adopt a copy of the gtest source? Are there any good reasons (e.g. licensing) not to do this? I'm generally not keen on repo bloat but AFAIU it's generally considered good practice to bundle test frameworks with project source code.
AV
I'm not sure where I read it but just last week I found out that Google had changed their recommendation concerning best-practice with google test...here it is:
https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-...
So using the source from libgtest-dev seems like a good option even though we can't control the version of it. Not sure about the gmock binaries, maybe need to compile that from source as well for the same reason listed above?
Lib2geom simply has the monolithic GTest source file included in its source tree. No problems so far.
2016-06-07 10:53 GMT-07:00 Christoffer Holmstedt <christoffer.holmstedt@...400...>:
I'm not sure where I read it but just last week I found out that Google had changed their recommendation concerning best-practice with google test...here it is:
https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-...
So using the source from libgtest-dev seems like a good option even though we can't control the version of it. Not sure about the gmock binaries, maybe need to compile that from source as well for the same reason listed above?
-- Christoffer Holmstedt
2016-06-07 19:32 GMT+02:00 Alex Valavanis <valavanisalex@...400...>:
OK, looking into this a little further, it seems that there is a Debian package libgtest-dev, which contains the Googletest source code, and a google-mock package, which provides the gmock binaries. It may be possible to adapt the CMake builds to allow us to use these packages. I'll look into it!
AV
On 7 June 2016 at 18:11, Alex Valavanis <valavanisalex@...400...> wrote:
Summary: If we want to run tests in the PPA, we probably need to include a copy of gtest source in our repo. Any objections?
Hi All,
Are there any objections to bundling a copy of the Google test framework source code into our trunk repo? At the moment, we provide the download-gtest.sh script for grabbing the gtest source from upstream. However, this presents a couple of issues:
- It's obviously dependent on a network connection to the upstream
packages being available
- We can't run the wget download in the Ubuntu builder
Can I suggest that we simply adopt a copy of the gtest source? Are there any good reasons (e.g. licensing) not to do this? I'm generally not keen on repo bloat but AFAIU it's generally considered good practice to bundle test frameworks with project source code.
AV
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Jun 14, 2016, at 11:41 PM, Krzysztof Kosiński wrote:
Lib2geom simply has the monolithic GTest source file included in its source tree. No problems so far.
2016-06-07 10:53 GMT-07:00 Christoffer Holmstedt <christoffer.holmstedt@...400...>:
I'm not sure where I read it but just last week I found out that Google had changed their recommendation concerning best-practice with google test...here it is:
https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-...
Yes, that had been the recommendation for many-a-year now. I've used it in many codebases (both open-source and proprietary) and it does well. Boost test is the other top contender but that requires built libs and we've been avoiding that for certain reasons.
Also now that Google has shut down their code hosting, GMock ended up getting bundled with GTest. Eventually that might be a viable one-stop solution. However, the release is still at 1.7.0 so I'd suggest staying with the older separated ones for now.
That package also ships CMakeLists.txt files, so you can just build it with their CMake rules. http://bazaar.launchpad.net/~unity-api-team/policykit-unity8/16.04/view /head:/tests/CMakeLists.txt#L5 You can just grab all of the source and have it build a library with that. Ted On Tue, 2016-06-07 at 18:32 +0100, Alex Valavanis wrote:
OK, looking into this a little further, it seems that there is a Debian package libgtest-dev, which contains the Googletest source code, and a google-mock package, which provides the gmock binaries. It may be possible to adapt the CMake builds to allow us to use these packages. I'll look into it!
AV
On 7 June 2016 at 18:11, Alex Valavanis <valavanisalex@...400...> wrote:
Summary: If we want to run tests in the PPA, we probably need to include a copy of gtest source in our repo. Any objections?
Hi All,
Are there any objections to bundling a copy of the Google test framework source code into our trunk repo? At the moment, we provide the download-gtest.sh script for grabbing the gtest source from upstream. However, this presents a couple of issues:
- It's obviously dependent on a network connection to the upstream
packages being available
- We can't run the wget download in the Ubuntu builder
Can I suggest that we simply adopt a copy of the gtest source? Are there any good reasons (e.g. licensing) not to do this? I'm generally not keen on repo bloat but AFAIU it's generally considered good practice to bundle test frameworks with project source code.
AV
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659 582;e _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Jun 07, 2016 at 06:32:08PM +0100, Alex Valavanis wrote:
OK, looking into this a little further, it seems that there is a Debian package libgtest-dev, which contains the Googletest source code, and a google-mock package, which provides the gmock binaries. It may be possible to adapt the CMake builds to allow us to use these packages. I'll look into it!
Yes, that'd be my first choice.
AV
On 7 June 2016 at 18:11, Alex Valavanis <valavanisalex@...400...> wrote:
Summary: If we want to run tests in the PPA, we probably need to include a copy of gtest source in our repo. Any objections?
Hi All,
Are there any objections to bundling a copy of the Google test framework source code into our trunk repo? At the moment, we provide the download-gtest.sh script for grabbing the gtest source from upstream. However, this presents a couple of issues:
- It's obviously dependent on a network connection to the upstream
packages being available
- We can't run the wget download in the Ubuntu builder
Can I suggest that we simply adopt a copy of the gtest source? Are there any good reasons (e.g. licensing) not to do this? I'm generally not keen on repo bloat but AFAIU it's generally considered good practice to bundle test frameworks with project source code.
AV
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (6)
-
Alex Valavanis -
Bryce Harrington -
Christoffer Holmstedt -
Jon A. Cruz -
Krzysztof Kosiński -
Ted Gould