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 <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 >> >> Alex > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core