Date
1 - 3 of 3
Cross-compiling or compiling on target VM?
arnaud.bienner@...
Hi,
We are starting a new project using Yocto to build a custom Linux image which matches our needs.
We are new to Yocto and still trying to figure out the best way to work with it.
Especially, if it is best to cross-compile or to build on a VM running an image of the target.
Some background:
Our target system is x86_64, and we are all working on x86_64 computers obviously.
For now, we don't have yet a physical target system so we are running the image generated by Yocto in VirtualBox or VMWare.
For practical reasons, since not all developers use the same OS (Windows, macOS) we decided to do all development work on Linux VM (Debian distribution) so everyone has the same system.
For now, we are cross-compiling applications using Yocto SDK in that Debian VM, copying it to the Yocto VM to run it.
Even though copying/deploying and running them could be somehow automated, since we are developing on a Linux VM anyway, I thought it could be best to build a Yocto image (maybe as an additional "dev" image based on the existing one) which contains all tools we need (gcc, cmake, etc.).
This way, we could execute the binaries (in particular the unit tests) locally.
For some of our unit tests in particular that we run at build time, it sounds easier to run them locally, compared to deploying them and running them remotely.
Any thoughts about this?
In advance, thanks a lot for your help.
Best regards,
Arnaud
We are starting a new project using Yocto to build a custom Linux image which matches our needs.
We are new to Yocto and still trying to figure out the best way to work with it.
Especially, if it is best to cross-compile or to build on a VM running an image of the target.
Some background:
Our target system is x86_64, and we are all working on x86_64 computers obviously.
For now, we don't have yet a physical target system so we are running the image generated by Yocto in VirtualBox or VMWare.
For practical reasons, since not all developers use the same OS (Windows, macOS) we decided to do all development work on Linux VM (Debian distribution) so everyone has the same system.
For now, we are cross-compiling applications using Yocto SDK in that Debian VM, copying it to the Yocto VM to run it.
Even though copying/deploying and running them could be somehow automated, since we are developing on a Linux VM anyway, I thought it could be best to build a Yocto image (maybe as an additional "dev" image based on the existing one) which contains all tools we need (gcc, cmake, etc.).
This way, we could execute the binaries (in particular the unit tests) locally.
For some of our unit tests in particular that we run at build time, it sounds easier to run them locally, compared to deploying them and running them remotely.
Any thoughts about this?
In advance, thanks a lot for your help.
Best regards,
Arnaud
Alexander Kanavin
Yocto has built-in qemu targets for this purpose, and associated infrastructure to start qemu VMs and run tests in them. But to make it practical, these qemu images need to be started on a baremetal Linux machine. So I'd suggest you start by giving all your developers Linux laptops.
Alex
On Fri, 24 Sept 2021 at 11:06, <arnaud.bienner@...> wrote:
Hi,
We are starting a new project using Yocto to build a custom Linux image which matches our needs.
We are new to Yocto and still trying to figure out the best way to work with it.
Especially, if it is best to cross-compile or to build on a VM running an image of the target.
Some background:
Our target system is x86_64, and we are all working on x86_64 computers obviously.
For now, we don't have yet a physical target system so we are running the image generated by Yocto in VirtualBox or VMWare.
For practical reasons, since not all developers use the same OS (Windows, macOS) we decided to do all development work on Linux VM (Debian distribution) so everyone has the same system.
For now, we are cross-compiling applications using Yocto SDK in that Debian VM, copying it to the Yocto VM to run it.
Even though copying/deploying and running them could be somehow automated, since we are developing on a Linux VM anyway, I thought it could be best to build a Yocto image (maybe as an additional "dev" image based on the existing one) which contains all tools we need (gcc, cmake, etc.).
This way, we could execute the binaries (in particular the unit tests) locally.
For some of our unit tests in particular that we run at build time, it sounds easier to run them locally, compared to deploying them and running them remotely.
Any thoughts about this?
In advance, thanks a lot for your help.
Best regards,
Arnaud
On 9/24/21 2:06 AM, arnaud.bienner@... wrote:
inherently Yocto project is a cross compiling infrastructure so lot of commonly used workflows will be around cross-compiling, however you can also leverage it in ways you described, where you build a development VM using yocto project itself which includes all the tools your developers would need and use that as build env + devtest env, see core-image-sato-sdk. However, this will be more of less a static env, which means devs wont be able to install packages like they might be doing with debian VM, you will have to either rebuild the VM or publish own feeds, but if you expect this to be static env then this might turn out to be ok. Advantage is that you will use same tools that your final target will use and you have ease of native development and folks not familiar with yocto can be effective as well. However this is not a common workflow that yocto project users might be using, so community support might be scarce.
Other option could be that you do cross builds on your debian VM and use qemux86-64 as target and run your tests using ptest framework so you will be running your target VM in qemu on top of your build running debian which is running on windows/MacOS or Linux baremetal. There might be some quirks to use qemu in VM but I think it should work out well. This also means that in future when you target real hardware ( I assume thats what you want eventually ) then not much changes, you add another MACHINE and workflow remains pretty much same. But this would require your devs to learn a bit of yocto-fu and cross-complation workflows.
Hi,there are different possibilities you have with all great tooling you get with yocto project, I think you have made a good choice.
We are starting a new project using Yocto to build a custom Linux image which matches our needs.
We are new to Yocto and still trying to figure out the best way to work with it.
Especially, if it is best to cross-compile or to build on a VM running an image of the target.
Some background:
Our target system is x86_64, and we are all working on x86_64 computers obviously.
For now, we don't have yet a physical target system so we are running the image generated by Yocto in VirtualBox or VMWare.
For practical reasons, since not all developers use the same OS (Windows, macOS) we decided to do all development work on Linux VM (Debian distribution) so everyone has the same system.
For now, we are cross-compiling applications using Yocto SDK in that Debian VM, copying it to the Yocto VM to run it.
Even though copying/deploying and running them could be somehow automated, since we are developing on a Linux VM anyway, I thought it could be best to build a Yocto image (maybe as an additional "dev" image based on the existing one) which contains all tools we need (gcc, cmake, etc.).
This way, we could execute the binaries (in particular the unit tests) locally.
For some of our unit tests in particular that we run at build time, it sounds easier to run them locally, compared to deploying them and running them remotely.
Any thoughts about this?
inherently Yocto project is a cross compiling infrastructure so lot of commonly used workflows will be around cross-compiling, however you can also leverage it in ways you described, where you build a development VM using yocto project itself which includes all the tools your developers would need and use that as build env + devtest env, see core-image-sato-sdk. However, this will be more of less a static env, which means devs wont be able to install packages like they might be doing with debian VM, you will have to either rebuild the VM or publish own feeds, but if you expect this to be static env then this might turn out to be ok. Advantage is that you will use same tools that your final target will use and you have ease of native development and folks not familiar with yocto can be effective as well. However this is not a common workflow that yocto project users might be using, so community support might be scarce.
Other option could be that you do cross builds on your debian VM and use qemux86-64 as target and run your tests using ptest framework so you will be running your target VM in qemu on top of your build running debian which is running on windows/MacOS or Linux baremetal. There might be some quirks to use qemu in VM but I think it should work out well. This also means that in future when you target real hardware ( I assume thats what you want eventually ) then not much changes, you add another MACHINE and workflow remains pretty much same. But this would require your devs to learn a bit of yocto-fu and cross-complation workflows.
In advance, thanks a lot for your help.
Best regards,
Arnaud