Why can't a Yocto SDK build a Yocto SDK?

Question

There are set of related questions here, because I suspect I am asking the wrong question. The related questions may help someone discern what my fundamental misunderstanding is.

I have worked through:

• https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html
• https://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html
• https://www.yoctoproject.org/docs/2.6/sdk-manual/sdk-manual.html

I'm looking for an single build environment from which I can use bitbake, and build a product for different target architectures.

This after all seems to be what the Yocto/OE holy grail is.

It seems like the most functional x86_64 environment is had from:

git clone git://git.yoctoproject.org/poky

It is more capable than the SDK's, but how do I cross-build this environment for another platform?

Is there an SDK that is as functional as this git clone'd environment? Meaning it has a working bitbake and I can cross-build bootable images for different targets?

Questions:

• Why can't an SDK build an SDK? (e.g. http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/buildtools/)

  • Why doesn't an SDK even include bitbake? (The ext SDK does, but doesn't like to add it to the path).
  • Why does an extensible SDK with properly sourced env (and bitbake added to the path) seem to prefer the distro-installed build tools instead of the ones in the SDK? (when using bitmake directly instead of devtool)

• Why is an SDK apparently tied to build for a particular machine or architecture, and apparently unable to cross-build for different architectures? The process for building an SDK even wishes the final architecture to be specified in advance

What I'm used to is a build-sysroot with the cross-toolchain running under some sort of pseudo/proot/chroot with my sources mounted into it.

I realise that Yocto/bitbake does this under the hood, all the recipe caching seems great, the git clone checkout seems powerful, the devtool workflow seems great, but then it all falls down when I try to standardise generation of this environment, or make it cross-compile.

(I’m expecting to source the environment file from a target directory containing some local conf files to specialise the build, and then use bitbake to make the build)

What have I missed? - thanks for reading this far ;-)

Answer 1

Reading from https://www.yoctoproject.org/docs/2.6.1/ref-manual/ref-manual.html#cross-development-toolchain

it seems that an SDK and eSDK are examples of a relocatable toolchain;

A relocatable toolchain used outside of BitBake by developers when developing applications that will run on a targeted device.

This sentence particularly gives the game away:

You can also find more information on using the relocatable toolchain in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual.

SO I guess the git-clone-poky checkout which builds the SDK and eSDK is:

A toolchain only used by and within BitBake when building an image for a target architecture

No doubt I am interested in:

toolchain concepts as they apply to the Yocto Project

and should:

see the "Cross-Development Toolchain Generation" section in the Yocto Project Overview and Concepts Manual https://www.yoctoproject.org/docs/2.6.1/overview-manual/overview-manual.html#cross-development-toolchain-generation

Certainly the first image makes it clear that the SDK is for building apps, not the image. I want to build the image (which of course may contain apps).

And so I may wish to make an SDK for other app builders, and incorporate their app into my sources and do the final build for them.

It may also be that the toolchain used for building an image can be run within the SDK so as to use the toolchain of the SDK rather than the host linux distro toolchain no, you can't

Answer 2

SDK is such a generic word that in the context of yocto, it can be miss interpreted and so your question is legit.

Yocto is a wonderful tool to build completely custom images and can be adjusted at all level (bootloader, kernel, applications) based on source fetched online. The SDK you can generate with yocto is as quoted from the documentation:

The Standard SDK provides a cross-development toolchain and libraries tailored to the contents of a specific image.

Based on my small experience with Yocto, you use meta layers to create and customize your environment. When your environment is setup, you can generate an SDK to easily cross compile your aplicative programs for your target machine. Yocto tool is way too powerful, heavy and complicated for developers who just focus on the aplicative part of a project. The SDK on the other side is perfect for that use but you can't change anything in the toolchain with it, you can only use it. If a bug or a patch needs to be applied in runtime libs for example, you need to regenerate the SDK and give this new versions to developers.

With that short explanations:

It is more capable than the SDK's, but how do I cross-build this environment for another platform?

You need to customize your Yocto meta layers to change from a platform to another.

Is there an SDK that is as functional as this git clone'd environment? Meaning it has a working bitbake and I can cross-build bootable images for different targets?

No, i don't think so

Why can't an SDK build an SDK?

Because that's not the philosophy of the SDK, sdk is a generated toolchain for a specific image to cross compile your programs, no more.

Why doesn't an SDK even include bitbake?

Bitbake is a tool to parse yocto recipe (so meta layers) and so, there is no need to have this tool in the SDK

Why is an SDK apparently tied to build for a particular machine or architecture, and apparently unable to cross-build for different architectures? The process for building an SDK even wishes the final architecture to be specified in advance

I think i already gave an answer to this question but, about the second part of your question. It is possible to be a little bit agile and start both the BSP and applications in parallel. Every week, you release a new SDK with BSP new changes an the toolchain is always up-to-date for developers (This is a very idealistic vision i admit)