From: Stephan Hoffmann <sho@relinux.de>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2] New package: googletest
Date: Tue, 05 Feb 2013 18:59:11 +0100 [thread overview]
Message-ID: <5111486F.6090907@relinux.de> (raw)
In-Reply-To: <20130205175752.00d8e32e@skate>
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
--
reLinux - Stephan Hoffmann
Am Schmidtgrund 124 50765 K?ln
Tel. +49.221.95595-19 Fax: -64
www.reLinux.de sho at reLinux.de
next prev parent reply other threads:[~2013-02-05 17:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-05 15:08 [Buildroot] [PATCH] New package: googletest Stephan Hoffmann
2013-02-05 15:18 ` [Buildroot] [PATCH v2] " Stephan Hoffmann
2013-02-05 15:47 ` Thomas Petazzoni
2013-02-05 16:27 ` Stephan Hoffmann
2013-02-05 16:57 ` Thomas Petazzoni
2013-02-05 17:01 ` Jeremy Rosen
2013-02-05 17:59 ` Stephan Hoffmann [this message]
2013-02-05 18:16 ` [Buildroot] [PATCH v3] New package: gtest Stephan Hoffmann
2013-03-04 10:28 ` Stephan Hoffmann
2013-03-17 22:22 ` Peter Korsgaard
2013-02-05 15:19 ` [Buildroot] [PATCH] New package: googletest Stephan Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5111486F.6090907@relinux.de \
--to=sho@relinux.de \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox