From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v7] gtest/gmock: bump to version 1.8.0
Date: Sun, 26 Feb 2017 15:05:25 +0100 [thread overview]
Message-ID: <20170226150525.359a21cf@free-electrons.com> (raw)
In-Reply-To: <1487784452-7424-1-git-send-email-casantos@datacom.ind.br>
Hello,
Thanks for this new version, but there's still one thing (the same
thing as before) that I don't understand.
On Wed, 22 Feb 2017 14:27:32 -0300, Carlos Santos wrote:
> +# GTest's CMakeLists.txt uses a tricky logic:
> +# - by default sets BUILD_GMOCK to ON and BUILD_GTEST to OFF
> +# - if BUILD_GMOCK is ON then builds gmock, which in its turn builds gtest,
> +# regardless the value of BUILD_GTEST
> +# - otherwise, if BUILD_GTEST is ON then build gtest, only
> +# So, to build only gtest we must set BUILD_GTEST to ON and BUILD_GMOCK to OFF
> +# to revert the default values. Setting both to ON is not really necessary but
> +# describes clearly what we intend to do.
Knowing this, why don't you simply do the much more obvious:
GTEST_CONF_OPTS += -DBUILD_GTEST=ON
ifeq ($(BR2_PACKAGE_GTEST_GMOCK),y)
GTEST_CONF_OPTS += -DBUILD_GMOCK=ON
else
GTEST_CONF_OPTS += -DBUILD_GMOCK=OFF
endif
instead of the very cryptic!
> +ifeq ($(BR2_PACKAGE_GTEST_GMOCK),)
> +GTEST_CONF_OPTS += -DBUILD_GMOCK=OFF
> +GTEST_CONF_OPTS += -DBUILD_GTEST=ON
> +endif
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-02-26 14:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-07 14:39 [Buildroot] [PATCH 1/1] gtest: bump to version 1.8.0 Fabrice Fontaine
2016-09-07 15:19 ` Carlos Santos
2016-09-07 22:20 ` [Buildroot] [PATCH 1/1] gtest/gmock: " Carlos Santos
2016-09-07 23:16 ` [Buildroot] [PATCH v2] " Carlos Santos
2016-09-11 12:09 ` Arnout Vandecappelle
2017-02-06 15:43 ` Romain Naour
2017-02-06 16:46 ` Carlos Santos
2017-02-06 16:54 ` Romain Naour
2017-02-11 11:32 ` [Buildroot] [PATCH v3] " Carlos Santos
2017-02-11 13:50 ` Romain Naour
2017-02-11 18:08 ` Carlos Santos
2017-02-11 18:11 ` [Buildroot] [PATCH v4] " Carlos Santos
2017-02-12 12:17 ` [Buildroot] [PATCH v5] " Carlos Santos
2017-02-12 14:15 ` Romain Naour
2017-02-12 14:37 ` Thomas Petazzoni
2017-02-12 14:37 ` Thomas Petazzoni
2017-02-12 15:02 ` Carlos Santos
2017-02-12 17:28 ` Thomas Petazzoni
2017-02-14 11:05 ` [Buildroot] [PATCH v6] " Carlos Santos
2017-02-22 17:27 ` [Buildroot] [PATCH v7] " Carlos Santos
2017-02-26 14:05 ` Thomas Petazzoni [this message]
2017-02-27 12:31 ` Carlos Santos
2017-03-01 22:09 ` Thomas Petazzoni
2017-03-02 11:34 ` Carlos Santos
2017-03-05 21:17 ` [Buildroot] [PATCH v6] " Thomas Petazzoni
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=20170226150525.359a21cf@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--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