| Message ID | 1360077510-6556-1-git-send-email-sho@relinux.de |
|---|---|
| State | Superseded |
| Headers | show |
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
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
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
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
>
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
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))
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