From: Jasper Orschulko <Jasper.Orschulko@iris-sensing.com>
To: "sakoman@gmail.com" <sakoman@gmail.com>,
"eero.aaltonen@vaisala.com" <eero.aaltonen@vaisala.com>
Cc: "openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>,
"martin@mko.dev" <martin@mko.dev>,
Daniel Baumgart <Daniel.Baumgart@iris-sensing.com>
Subject: Re: [OE-core][dunfell 16/18] cmake: FindGTest: Add target for gmock library
Date: Mon, 13 Dec 2021 17:41:15 +0000 [thread overview]
Message-ID: <059f8a1a943ea112a3373950b79822125b175865.camel@iris-sensing.com> (raw)
In-Reply-To: <239c054bb94c0c986865ab0bea221973a2650f37.camel@vaisala.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Eero,
my first reflex was to say, that I don't believe this to be necessary.
As you already said, these variables aren't documented and thus I'd
argue that you don't have to consider them for maintaining backwards
compatibility during backports. I personally see this as a bug on our
part and as a coincidence that our setup worked pre-patch.
However, I'm not sure WHY those two variables where actually used by us
or where they originated from. Going as far back as cmake 3.0, these
variables where never documented, however doing a quick search for
those reveals that they actually are used in other (older?) projects.
So I'm not quite sure how many other users might be affected by this.
Maybe we actually SHOULD keep supporting them for the LTS branch, just
in case?
- --
With best regards
Jasper Orschulko
DevOps Engineer
Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com
• • • • • • • • • • • • • • • • • • • • • • • • • •
iris-GmbH
infrared & intelligent sensors
Schnellerstraße 1-5 | 12439 Berlin
https://iris-sensing.com/
On Mon, 2021-12-13 at 15:03 +0200, Eero Aaltonen wrote:
> On Fri, 2021-12-10 at 18:49 +0000, Jasper Orschulko wrote:
> > Hello everyone,
> >
> > after some digging we identified the issue to be on our part.
> > We have been using "GTEST_LIBRARY" and "GTEST_MAIN_LIBRARY" in our
> > CMake scripts instead of "GTEST_LIBRARIES" and
> > "GTEST_MAIN_LIBRARIES",
> > as described in the cmake docs:
> >
> https://cmake.org/cmake/help/v3.16/module/FindGTest.html#result-variables
>
> Thank you for providing more details.
>
> The gmock target can be backported to dunfell in an alternative way,
> by
> leaving out the
> find_package(GTest QUIET NO_MODULE)
>
> call and subsequent lines and letting the FindModule create all the
> definitions. This would leave also the undocumented variables intact,
> if that is desired.
>
> This should be as simple as dropping the lines
> ----------------------------------------------
> # first specifically look for the CMake version of GTest
> find_package(GTest QUIET NO_MODULE)
>
> # if we found the GTest cmake package then we are done, and
> # can print what we found and return.
> if(GTest_FOUND)
> set(GTEST_FOUND ${GTest_FOUND})
> FIND_PACKAGE_HANDLE_STANDARD_ARGS(GTest HANDLE_COMPONENTS
> CONFIG_MODE)
>
> set(GTEST_LIBRARIES GTest::gtest)
> set(GTEST_MAIN_LIBRARIES GTest::gtest_main)
>
> __gtest_define_backwards_compatible_library_targets()
>
> return()
> endif()
> ----------------------------------------------
>
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmG3hbsACgkQYgqew07V
MNW6Gwf8DcYj0KlqNSLpB3tlsplI4Wac9mfxAd/g2BoKcyekRK2IArMJKzNDEhi6
GqKar0z3QgRZQrF54X63/MnhaqIypHef+8YyUPVVYhq+HUZSXc+6c3SjIdVBBJn8
G04/pxmoLybBvqMmFcP67qhFlojo7yW2viK8stdVZ49VwfE3XIq3fSxrqE6xQq1V
nOoZw5DRLqgCGpeB41OebYXE1bOIX3WOgk5Pzkuf4Iq9bLDoWg5zXSxw0djYCMZS
2E6kHIwJavEVKhmQoC2IpiPrZ4cJQ57JZvIR95HsFkG/C/N6sKXlJu2VLId+5xdb
IwUexGr3vUCXGqrUTWOZE6kxhdo74Q==
=/Myf
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2021-12-13 17:41 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-03 18:18 [OE-core][dunfell 00/18] Patch review Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 01/18] cve-extra-exclusions: add db CVEs to exclusion list Steve Sakoman
2021-12-05 12:39 ` Richard Purdie
2021-12-05 14:05 ` Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 02/18] glib-2.0: Add security fixes Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 03/18] busybox: Fix for CVE-2021-42374 Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 04/18] busybox: Fix for CVE-2021-42376 Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 05/18] vim: fix CVE-2021-3968 and CVE-2021-3973 Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 06/18] ncurses: Fix for CVE-2021-39537 Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 07/18] libsolv: update tag for missing CVEs Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 08/18] bind: update to 9.11.33 Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 09/18] bind: update to 9.11.34 Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 10/18] bind: update to 9.11.35 Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 11/18] libdnf: Backport bugfix for upgrade calc Steve Sakoman
2021-12-03 18:18 ` [OE-core][dunfell 12/18] dnf: Backport bugfix for upgrade Steve Sakoman
2021-12-03 18:19 ` [OE-core][dunfell 13/18] libunwind: Backport a fix for -fno-common option to compile Steve Sakoman
2021-12-03 18:19 ` [OE-core][dunfell 14/18] buildhistory: Fix srcrevs output Steve Sakoman
2021-12-03 18:19 ` [OE-core][dunfell 15/18] oeqa/parselogs: Fix quoting Steve Sakoman
2021-12-03 18:19 ` [OE-core][dunfell 16/18] cmake: FindGTest: Add target for gmock library Steve Sakoman
2021-12-09 17:38 ` Jasper Orschulko
2021-12-09 19:32 ` Steve Sakoman
2021-12-10 18:49 ` Jasper Orschulko
2021-12-13 13:03 ` Eero Aaltonen
2021-12-13 17:41 ` Jasper Orschulko [this message]
2021-12-03 18:19 ` [OE-core][dunfell 17/18] scripts/checklayer/common.py: Fixed a minor grammatical error Steve Sakoman
2021-12-03 18:19 ` [OE-core][dunfell 18/18] README.OE-Core.md: update URLs Steve Sakoman
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=059f8a1a943ea112a3373950b79822125b175865.camel@iris-sensing.com \
--to=jasper.orschulko@iris-sensing.com \
--cc=Daniel.Baumgart@iris-sensing.com \
--cc=eero.aaltonen@vaisala.com \
--cc=martin@mko.dev \
--cc=openembedded-core@lists.openembedded.org \
--cc=sakoman@gmail.com \
/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