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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.