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.
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?
On 10 June 2018 at 17:04, akuster808 <akuster...@gmail.com> wrote:
> On 06/10/2018 12:25 AM, Alexander Kanavin wrote:
>> 2018-06-09 23:00 GMT+03:00 Armin Kuster <akuster...@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
> Openembedded-core mailing list
Openembedded-core mailing list