Re: Building for both target and host
Alexander Kanavin
One option is to actually build an image for a qemux86_64 machine with the items you need (or qemuarm64 if that's your build host), then use 'runqemu kvm' to get native execution speed in a fully virtualized environment. 'native' recipes are generally meant as a springboard to get the binaries that are needed to build target recipes, and not a way to do 'native testing'.
Alex
On Wed, 24 Aug 2022 at 16:38, Maik Vermeulen <maik.vermeulen@...> wrote:
Hi Richard,Thanks, that seems like pretty much what I need!However, currently the recipes in the dependency chain don't all contain 'native' counterparts.Most actually wouldn't really need to for the executable to be built.Is there a way to neatly work around this too?On Wed, Aug 24, 2022 at 3:01 PM Richard Purdie <richard.purdie@...> wrote:On Wed, 2022-08-24 at 14:18 +0200, Maik Vermeulen wrote:
> Hi,
>
> We have a recipe with a CMake project which works fine on target, but
> ideally we would like to test functionality on our host systems
> first.
> How can we also have it generate executables for the host system?
>
> Do we need to make changes to the recipe, CMakeLists.txt, or both?
> I read something about autotools, but it's completely new to me.
>
> Any hints on what the easiest approach would be would be greatly
> appreciated!
BBCLASSEXTEND = "native"
would create a variant of the recipe X as X-native which would run on
the build host. That may or may not be what you're looking for :)
Cheers,
Richard
Automotive Campus 70 —5708 JZ Helmond, the NetherlandsThis email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298.
