Patchwork [v2] New package: googletest

login
register
mail settings
Submitter Stephan Hoffmann
Date Feb. 5, 2013, 3:18 p.m.
Message ID <1360077510-6556-1-git-send-email-sho@relinux.de>
Download mbox | patch
Permalink /patch/218273/
State Superseded
Headers show

Comments

Stephan Hoffmann - Feb. 5, 2013, 3:18 p.m.
Google's framework for writing C++ tests on a variety of platforms (Linux,
Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit
architecture. Supports automatic test discovery, a rich set of assertions,
user-defined assertions, death tests, fatal and non-fatal failures, value-
and type-parameterized tests, various options for running the tests, and XML
test report generation.

Googletest also allows to easily build testsuites for C programs.

This package allows running testsuites on the target which might be
advanteous in certain cases.

http://code.google.com/p/googletest/

Signed-off-by: Stephan Hoffmann <sho@relinux.de>
---
 package/Config.in       |    1 +
 package/gtest/Config.in |   20 ++++++++++++++++++++
 package/gtest/gtest.mk  |   23 +++++++++++++++++++++++
 3 files changed, 44 insertions(+), 0 deletions(-)
 create mode 100644 package/gtest/Config.in
 create mode 100644 package/gtest/gtest.mk
Thomas Petazzoni - Feb. 5, 2013, 3:47 p.m.
Dear Stephan Hoffmann,

On Tue,  5 Feb 2013 16:18:30 +0100, Stephan Hoffmann wrote:
> Google's framework for writing C++ tests on a variety of platforms (Linux,
> Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit
> architecture. Supports automatic test discovery, a rich set of assertions,
> user-defined assertions, death tests, fatal and non-fatal failures, value-
> and type-parameterized tests, various options for running the tests, and XML
> test report generation.
> 
> Googletest also allows to easily build testsuites for C programs.
> 
> This package allows running testsuites on the target which might be
> advanteous in certain cases.

Typo: advantageous.

> --- /dev/null
> +++ b/package/gtest/Config.in
> @@ -0,0 +1,20 @@
> +config BR2_PACKAGE_GTEST

Maybe the package directory should be named "googletest" and the option
BR2_PACKAGE_GOOGLETEST. But I'm not sure since the upstream tarball is
just "gtest".

> +	bool "googletest"
> +	depends on BR2_USE_WCHAR && BR2_TOOLCHAIN_HAS_THREADS && BR2_INSTALL_LIBSTDCPP
> +	help
> +	  Google's framework for writing C++ tests on a variety of platforms (Linux,
> +	  Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit
> +	  architecture. Supports automatic test discovery, a rich set of assertions,
> +	  user-defined assertions, death tests, fatal and non-fatal failures, value-
> +	  and type-parameterized tests, various options for running the tests, and XML
> +	  test report generation.
> +
> +	  Googletest also allows to easily build testsuites for C programs.
> +
> +	  This package allows running testsiuites on the target which might be

testsuites

> +	  advanteous in certain cases.

advantageous

> +GTEST_VERSION = 1.6.0
> +GTEST_SOURCE = gtest-1.6.0.zip
> +GTEST_SITE = http://googletest.googlecode.com/files/
> +GTEST_INSTALL_STAGING = YES
> +GTEST_INSTALL_TARGET = NO

Even though I understand that it is composed only of a static library,
I find this GTEST_INSTALL_TARGET = NO a bit strange. But well, ok.

> +
> +define GTEST_EXTRACT_CMDS
> +	unzip  $(DL_DIR)/$(GTEST_SOURCE) -d $(BUILD_DIR)
> +endef

Maybe some day we will want to have support in the package
infrastructure to extract .zip files (we already have 3-4 packages that
could benefit from this). But it can be done later.

> +define GTEST_INSTALL_STAGING_CMDS
> +	$(INSTALL) -D -m 0755 $(@D)/libgtest.a $(STAGING_DIR)/usr/lib/libgtest.a
> +	$(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/include/gtest/
> +	cp -rp $(@D)/include/gtest/* $(STAGING_DIR)/usr/include/gtest/
> +endef

There's no "make install" or something like that?

Thanks,

Thomas
Stephan Hoffmann - Feb. 5, 2013, 4:27 p.m.
Am 05.02.2013 16:47, schrieb Thomas Petazzoni:
> Dear Stephan Hoffmann,
>
> On Tue,  5 Feb 2013 16:18:30 +0100, Stephan Hoffmann wrote:
>> Google's framework for writing C++ tests on a variety of platforms (Linux,
>> Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit
>> architecture. Supports automatic test discovery, a rich set of assertions,
>> user-defined assertions, death tests, fatal and non-fatal failures, value-
>> and type-parameterized tests, various options for running the tests, and XML
>> test report generation.
>>
>> Googletest also allows to easily build testsuites for C programs.
>>
>> This package allows running testsuites on the target which might be
>> advanteous in certain cases.
> Typo: advantageous.
>
>> --- /dev/null
>> +++ b/package/gtest/Config.in
>> @@ -0,0 +1,20 @@
>> +config BR2_PACKAGE_GTEST
> Maybe the package directory should be named "googletest" and the option
> BR2_PACKAGE_GOOGLETEST. But I'm not sure since the upstream tarball is
> just "gtest".
Hello Thomas,

first I named it googletest, but since it is named gtest upstream and
unzip produces a directory with this name I decided to changed it.
>
>> +	bool "googletest"
>> +	depends on BR2_USE_WCHAR && BR2_TOOLCHAIN_HAS_THREADS && BR2_INSTALL_LIBSTDCPP
>> +	help
>> +	  Google's framework for writing C++ tests on a variety of platforms (Linux,
>> +	  Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit
>> +	  architecture. Supports automatic test discovery, a rich set of assertions,
>> +	  user-defined assertions, death tests, fatal and non-fatal failures, value-
>> +	  and type-parameterized tests, various options for running the tests, and XML
>> +	  test report generation.
>> +
>> +	  Googletest also allows to easily build testsuites for C programs.
>> +
>> +	  This package allows running testsiuites on the target which might be
> testsuites
>
>> +	  advanteous in certain cases.
> advantageous
>
>> +GTEST_VERSION = 1.6.0
>> +GTEST_SOURCE = gtest-1.6.0.zip
>> +GTEST_SITE = http://googletest.googlecode.com/files/
>> +GTEST_INSTALL_STAGING = YES
>> +GTEST_INSTALL_TARGET = NO
> Even though I understand that it is composed only of a static library,
> I find this GTEST_INSTALL_TARGET = NO a bit strange. But well, ok.
Yes, it is, but when there is nothing to install? Maybe it's also
possible to compile it to a .so, but I am not sure if it's worth the
effort. This way we can use googletest on the target and, when the
testuites are not instaled, do not waste any space there.

BTW: Running googletest on the target out of eclipse works well.
>
>> +
>> +define GTEST_EXTRACT_CMDS
>> +	unzip  $(DL_DIR)/$(GTEST_SOURCE) -d $(BUILD_DIR)
>> +endef
> Maybe some day we will want to have support in the package
> infrastructure to extract .zip files (we already have 3-4 packages that
> could benefit from this). But it can be done later.
That would be nice.
>
>> +define GTEST_INSTALL_STAGING_CMDS
>> +	$(INSTALL) -D -m 0755 $(@D)/libgtest.a $(STAGING_DIR)/usr/lib/libgtest.a
>> +	$(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/include/gtest/
>> +	cp -rp $(@D)/include/gtest/* $(STAGING_DIR)/usr/include/gtest/
>> +endef
> There's no "make install" or something like that?
I didn't find any. Of course it would be nicer. As far as I understand
the documentation one shall point the compiler and linker to the build
directory.

Thanx for the review. I'll provide a fixed patch later.

Regards

Stephan
>
> Thanks,
>
> Thomas
Thomas Petazzoni - Feb. 5, 2013, 4:57 p.m.
Dear Stephan Hoffmann,

On Tue, 05 Feb 2013 17:27:48 +0100, Stephan Hoffmann wrote:

> >> --- /dev/null
> >> +++ b/package/gtest/Config.in
> >> @@ -0,0 +1,20 @@
> >> +config BR2_PACKAGE_GTEST
> > Maybe the package directory should be named "googletest" and the option
> > BR2_PACKAGE_GOOGLETEST. But I'm not sure since the upstream tarball is
> > just "gtest".
> Hello Thomas,
> 
> first I named it googletest, but since it is named gtest upstream and
> unzip produces a directory with this name I decided to changed it.

Ok. The fact that we don't control the unzip output directory is a bit
annoying, but it's a separate matter.

In general we really try to keep a 1:1 mapping between:
 * the option name
 * the directory name
 * the name of the label attached to the configuration option in the
   menuconfig

With the current proposal, people would see a "googletest" label in
menuconfig, and might therefore look for package/googletest/... which
won't exist.

> > Even though I understand that it is composed only of a static library,
> > I find this GTEST_INSTALL_TARGET = NO a bit strange. But well, ok.
> Yes, it is, but when there is nothing to install? Maybe it's also
> possible to compile it to a .so, but I am not sure if it's worth the
> effort. This way we can use googletest on the target and, when the
> testuites are not instaled, do not waste any space there.

Ok.

> BTW: Running googletest on the target out of eclipse works well.

Does it mean that you're using the Eclipse Buildroot plugin?

> I didn't find any. Of course it would be nicer. As far as I understand
> the documentation one shall point the compiler and linker to the build
> directory.

Ok.

Thomas
Jeremy Rosen - Feb. 5, 2013, 5:01 p.m.
on a slightly related note, the gperftools were previously known as googleperftools

so I think settling for gtest rather than googletest would make sense since its the direction google seems to be generally moving

    Cordialement

    Jérémy Rosen

fight key loggers : write some perl using vim

----- Mail original -----
> Dear Stephan Hoffmann,
> 
> On Tue, 05 Feb 2013 17:27:48 +0100, Stephan Hoffmann wrote:
> 
> > >> --- /dev/null
> > >> +++ b/package/gtest/Config.in
> > >> @@ -0,0 +1,20 @@
> > >> +config BR2_PACKAGE_GTEST
> > > Maybe the package directory should be named "googletest" and the
> > > option
> > > BR2_PACKAGE_GOOGLETEST. But I'm not sure since the upstream
> > > tarball is
> > > just "gtest".
> > Hello Thomas,
> > 
> > first I named it googletest, but since it is named gtest upstream
> > and
> > unzip produces a directory with this name I decided to changed it.
> 
> Ok. The fact that we don't control the unzip output directory is a
> bit
> annoying, but it's a separate matter.
> 
> In general we really try to keep a 1:1 mapping between:
>  * the option name
>  * the directory name
>  * the name of the label attached to the configuration option in the
>    menuconfig
> 
> With the current proposal, people would see a "googletest" label in
> menuconfig, and might therefore look for package/googletest/... which
> won't exist.
> 
> > > Even though I understand that it is composed only of a static
> > > library,
> > > I find this GTEST_INSTALL_TARGET = NO a bit strange. But well,
> > > ok.
> > Yes, it is, but when there is nothing to install? Maybe it's also
> > possible to compile it to a .so, but I am not sure if it's worth
> > the
> > effort. This way we can use googletest on the target and, when the
> > testuites are not instaled, do not waste any space there.
> 
> Ok.
> 
> > BTW: Running googletest on the target out of eclipse works well.
> 
> Does it mean that you're using the Eclipse Buildroot plugin?
> 
> > I didn't find any. Of course it would be nicer. As far as I
> > understand
> > the documentation one shall point the compiler and linker to the
> > build
> > directory.
> 
> Ok.
> 
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
Stephan Hoffmann - Feb. 5, 2013, 5:59 p.m.
Am 05.02.2013 17:57, schrieb Thomas Petazzoni:
> Dear Stephan Hoffmann,
>
> On Tue, 05 Feb 2013 17:27:48 +0100, Stephan Hoffmann wrote:
>
>>>> --- /dev/null
>>>> +++ b/package/gtest/Config.in
>>>> @@ -0,0 +1,20 @@
>>>> +config BR2_PACKAGE_GTEST
>>> Maybe the package directory should be named "googletest" and the option
>>> BR2_PACKAGE_GOOGLETEST. But I'm not sure since the upstream tarball is
>>> just "gtest".
>> Hello Thomas,
>>
>> first I named it googletest, but since it is named gtest upstream and
>> unzip produces a directory with this name I decided to changed it.
> Ok. The fact that we don't control the unzip output directory is a bit
> annoying, but it's a separate matter.
>
> In general we really try to keep a 1:1 mapping between:
>  * the option name
>  * the directory name
>  * the name of the label attached to the configuration option in the
>    menuconfig
>
> With the current proposal, people would see a "googletest" label in
> menuconfig, and might therefore look for package/googletest/... which
> won't exist.
That's right, I think I'll name it gtest everywhere, as also Jeremy
Rosen proposes.
>
>>> Even though I understand that it is composed only of a static library,
>>> I find this GTEST_INSTALL_TARGET = NO a bit strange. But well, ok.
>> Yes, it is, but when there is nothing to install? Maybe it's also
>> possible to compile it to a .so, but I am not sure if it's worth the
>> effort. This way we can use googletest on the target and, when the
>> testuites are not instaled, do not waste any space there.
> Ok.
>
>> BTW: Running googletest on the target out of eclipse works well.
> Does it mean that you're using the Eclipse Buildroot plugin?
Yes, I played around with it a little and I like it. It gives a real
jumpstart into cross development for buildroot targets.
>> I didn't find any. Of course it would be nicer. As far as I understand
>> the documentation one shall point the compiler and linker to the build
>> directory.
> Ok.
>
> Thomas

Patch

diff --git a/package/Config.in b/package/Config.in
index 2f219b6..845fe57 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -541,6 +541,7 @@  source "package/fftw/Config.in"
 source "package/libargtable2/Config.in"
 source "package/argp-standalone/Config.in"
 source "package/boost/Config.in"
+source "package/gtest/Config.in"
 source "package/libatomic_ops/Config.in"
 source "package/libcap/Config.in"
 source "package/libcap-ng/Config.in"
diff --git a/package/gtest/Config.in b/package/gtest/Config.in
new file mode 100644
index 0000000..c7581b5
--- /dev/null
+++ b/package/gtest/Config.in
@@ -0,0 +1,20 @@ 
+config BR2_PACKAGE_GTEST
+	bool "googletest"
+	depends on BR2_USE_WCHAR && BR2_TOOLCHAIN_HAS_THREADS && BR2_INSTALL_LIBSTDCPP
+	help
+	  Google's framework for writing C++ tests on a variety of platforms (Linux,
+	  Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit
+	  architecture. Supports automatic test discovery, a rich set of assertions,
+	  user-defined assertions, death tests, fatal and non-fatal failures, value-
+	  and type-parameterized tests, various options for running the tests, and XML
+	  test report generation.
+
+	  Googletest also allows to easily build testsuites for C programs.
+
+	  This package allows running testsiuites on the target which might be
+	  advanteous in certain cases.
+
+	  http://code.google.com/p/googletest/
+
+comment "googletest requires a toolchain with c++, WCHAR and PTHREADS support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP
diff --git a/package/gtest/gtest.mk b/package/gtest/gtest.mk
new file mode 100644
index 0000000..4090c14
--- /dev/null
+++ b/package/gtest/gtest.mk
@@ -0,0 +1,23 @@ 
+#############################################################
+#
+# googletest
+#
+#############################################################
+
+GTEST_VERSION = 1.6.0
+GTEST_SOURCE = gtest-1.6.0.zip
+GTEST_SITE = http://googletest.googlecode.com/files/
+GTEST_INSTALL_STAGING = YES
+GTEST_INSTALL_TARGET = NO
+
+define GTEST_EXTRACT_CMDS
+	unzip  $(DL_DIR)/$(GTEST_SOURCE) -d $(BUILD_DIR)
+endef
+
+define GTEST_INSTALL_STAGING_CMDS
+	$(INSTALL) -D -m 0755 $(@D)/libgtest.a $(STAGING_DIR)/usr/lib/libgtest.a
+	$(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/include/gtest/
+	cp -rp $(@D)/include/gtest/* $(STAGING_DIR)/usr/include/gtest/
+endef
+
+$(eval $(cmake-package))