build system derived toolchain in Yocto

Question

I have a problem starting from the rocko upgrade and related to the Recipe-specific Sysroots introduced in Yocto 2.3

Our project uses cmake. So our recipe has:

DEPENDS = "cmake-native [...]"

So cmake ends up in build/tmp/work/cortexa5hf-neon-poky-linux-gnueabi/component/1.0-r0/recipe-sysroot-native/usr/bin/cmake So when building inside yocto everything is ok.

When we build outside yocto, we use the cross-toolchain generated and populated within the Build Directory:

$ bitbake meta-ide-toolchain

and then source the environment:

$ source build/tmp/environment-setup-cortexa5hf-neon-poky-linux-gnueabi

On rocko OECORE_NATIVE_SYSROOT is set to [...]/build/tmp/work/cortexa5hf-neon-poky-linux-gnueabi/meta-ide-support/1.0-r3/recipe-sysroot-native - which doesn't have cmake:

  $ which cmake
  $

So no cmake was found...

And on Krogoth it was build/tmp/sysroots/x86_64-linux - cmake is there:

$ which cmake
  <full path>/build/tmp/sysroots/x86_64-linux/usr/bin/cmake

How to correctly setup a toolchain derived from the build directory in order to build outside Yocto ?

Is there any reason to use SDK (toolchain) directly from a build directory of OE? It shouldn't be used that way... SDK should be installed (via shell script inside deploy/sdk/ directory) and used from the installed location. We are using cmake for our software and also in SDK without any problem (I can briefly describe the configuration if you want). — Tomas Novotny
The idea was that we have the build directory for building our project + full image, so everything is already there, already setup, all the tools+libraries etc. — StackedUser
If a new dependency is added, your environment is updated during bitbaking the project, so everything is updated "automatically" when you are going to build outside. Generating a installer and then installing that in some other locations involves extra, manual steps. Also if dependencies are added, you have to manualy generate it again and install it. So it didn't look that simple when we started the project, and using the toolchain derived from the build directory was more "natural"... — StackedUser
As I remember that build directory toolchain (build/tmp/environment-setup-cortexa5hf-neon-poky-linux-gnueabi) was also used and needed if one was going to use Eclipse for building a Yocto project. But maybe, I'm missing something ... (?) Describing you configuration will certainly help! — StackedUser
Yes, I see and understand your reasons. We are installing SDK on each developer's computer and as you wrote, we need to update it on every change (i.e. addition/upgrade of a library). It is not so frequent fortunately. On the other hand, our developers don't have OE on their computers. And we are also using Eclipse. Anyway, did you try Extensible SDK? It might suit your needs and it is encouraged way for the development. — Tomas Novotny

StackedUser StackedUser · Accepted Answer · 2018-02-09T12:39:12

I ended up not to use meta-ide-support, but instead I've added the support of generating the toolchain to my own recipe (my component): that is my final intention, to be able to also build my component outside Yocto.

So when I do a bitbake my-component beside building the component, the toolchain necessary to build the component outside Yocto is also generated.

In my recipe I've added some of the code from the meta-ide-support:

inherit toolchain-scripts

do_populate_ide_support () {
  toolchain_create_tree_env_script
}
addtask populate_ide_support before do_build after do_install

And now when I build my recipe I also get a environment-setup script in the build/tmp/ directory - same location as the meta-ide-toolchain used before.

Now everything is setup correctly:

OECORE_NATIVE_SYSROOT is set to [...]/build/tmp/work/cortexa5hf-neon-poky-linux-gnueabi/component/1.0/recipe-sysroot-native

build system derived toolchain in Yocto

1 Answers