All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Burton, Ross" <ross.burton@intel.com>
To: akuster808 <akuster808@gmail.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/2] selftest: add cmake test
Date: Mon, 11 Jun 2018 13:15:26 +0100	[thread overview]
Message-ID: <CAJTo0LarSUWvzyweD1MMbzMCOOBH-95NSpQC67Mz9D5kAcJdLA@mail.gmail.com> (raw)
In-Reply-To: <ea8c1a44-c10a-d693-578f-04ac8f4a4d51@gmail.com>

Well the problem in 12762 is that cmake *hardcodes a list of valid
boost versions*, and I'm struggling to understand why this would seem
like a good idea.

Some thoughts:
1) We definitely need a selftest for cmake.  We have a few build-stuff
test cases already (lzip, cpio, galculator in sdk and runtime, some
other in devtool's selftest).  I believe they need consolidation
(repeated for runtime and SDK tests) and review (they're all
autotools-based).  We should definitely be exercising that the build
systems work on target.
2) 12762 is a very specific problem with cmake.  Do we want to add a
whole selftest just for this?  Would it be easier to just patch cmake
to handle all versions?

Ross

On 10 June 2018 at 17:04, akuster808 <akuster808@gmail.com> wrote:
>
>
> On 06/10/2018 12:25 AM, Alexander Kanavin wrote:
>> 2018-06-09 23:00 GMT+03:00 Armin Kuster <akuster808@gmail.com>:
>>> +DEPENDS = "boost"
>>
>>
>>> +find_package(Boost 1.60 REQUIRED
>>> +    COMPONENTS
>>> +        unit_test_framework
>>> +)
>>
>> Is it possible to use something else than boost here, if we want to
>> test cmake's ability to find compoments?
> I am not a cmake expert by any means. I just took a testcase given that
> found a problem that I fixed earlier this week. I have not other idea
> one would ensure folks don't break cmake when the update packages.
>
>> So that the build time is as
>> quick as possible - boost isn't particularly fast.
>
> - armin
>>
>> Alex
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


  reply	other threads:[~2018-06-11 12:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-09 20:00 [PATCH 0/2] Adding cmake selftest Armin Kuster
2018-06-09 20:00 ` [PATCH 1/2] selftest: add cmake test Armin Kuster
2018-06-10  7:25   ` Alexander Kanavin
2018-06-10 16:04     ` akuster808
2018-06-11 12:15       ` Burton, Ross [this message]
2018-06-09 20:00 ` [PATCH 2/2] selftest: add cmake oeqa portion Armin Kuster
2018-06-10  7:22   ` Alexander Kanavin
2018-06-11 13:06   ` Burton, Ross

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=CAJTo0LarSUWvzyweD1MMbzMCOOBH-95NSpQC67Mz9D5kAcJdLA@mail.gmail.com \
    --to=ross.burton@intel.com \
    --cc=akuster808@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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.