Why can't a Yocto SDK build a Yocto SDK?Android SDK installation doesn't find JDKWhat are the Android SDK build-tools, platform-tools and tools? And which version should be used?Is there a way to build a yocto image in Yocto(1.8) with wandboard-solo as the target machine?Yocto: cannot build meta-monoAdding a Yocto project to my SVNAdding new recipe to Yocto fails during generate root fsYocto SDK with cmake toolchain filestdint.h “no such file or directory” error on yocto sdkIn yocto (poky) why is the layers config in the build/ folder?Add packages to yocto host sdk
Can you grapple/shove with the Hunter Ranger's Whirlwind Attack?
Sleeping solo in a double sleeping bag
How to dismiss intrusive questions from a colleague with whom I don't work?
Are required indicators necessary for radio buttons?
Should my "average" PC be able to discern the potential of encountering a gelatinous cube from subtle clues?
Something in the TV
How to create a summation symbol with a vertical bar?
Does adding the 'precise' tag to daggers break anything?
Can you feel passing through the sound barrier in an F-16?
Starships without computers?
Is there a known non-euclidean geometry where two concentric circles of different radii can intersect? (as in the novel "The Universe Between")
How can I pack my food so it doesn't smell?
Is a butterfly one or two animals?
How to think about joining a company whose business I do not understand?
Why were movies shot on film shot at 24 frames per second?
Was Tuvok bluffing when he said that Voyager's transporters rendered the Kazon weapons useless?
Potential new partner angry about first collaboration - how to answer email to close up this encounter in a graceful manner
Metal that glows when near pieces of itself
Is refusing to concede in the face of an unstoppable Nexus combo punishable?
Are thrust levers synchronized by default when pushed/pulled?
Ask for a paid taxi in order to arrive as early as possible for an interview within the city
The teacher logged me in as administrator for doing a short task, is the whole system now compromised?
Overwrite file only if data
Why is Boris Johnson visiting only Paris & Berlin if every member of the EU needs to agree on a withdrawal deal?
Why can't a Yocto SDK build a Yocto SDK?
Android SDK installation doesn't find JDKWhat are the Android SDK build-tools, platform-tools and tools? And which version should be used?Is there a way to build a yocto image in Yocto(1.8) with wandboard-solo as the target machine?Yocto: cannot build meta-monoAdding a Yocto project to my SVNAdding new recipe to Yocto fails during generate root fsYocto SDK with cmake toolchain filestdint.h “no such file or directory” error on yocto sdkIn yocto (poky) why is the layers config in the build/ folder?Add packages to yocto host sdk
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
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 ;-)
sdk yocto extensible
asked Mar 14 at 15:10
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
add a comment |
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 ;-)
sdk yocto extensible
asked Mar 14 at 15:10
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
I never tried ext-sdk, but what I generally do is working directly with Yocto layers & recipes, withpoky,meta-openembeddedplus manufacturer layer, iemeta-intel. Then I add a personal layer for distro specifics and another one for BSP modifications. If I want to support multiples machines, I add corresponding vendor layer + personal BSP layer. I (jenkins jobs) only generate standard SDK for developers and they usually work only on one particular machine. Don't know if this helps.
– Nayfe
Mar 16 at 19:39
add a comment |
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 ;-)
sdk yocto extensible
asked Mar 14 at 15:10
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
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 ;-)
sdk yocto extensible
sdk yocto extensible
asked Mar 14 at 15:10
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
asked Mar 14 at 15:10
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
asked Mar 14 at 15:10
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
asked Mar 14 at 15:10
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
asked Mar 14 at 15:10
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
5693 silver badges15 bronze badges
I never tried ext-sdk, but what I generally do is working directly with Yocto layers & recipes, withpoky,meta-openembeddedplus manufacturer layer, iemeta-intel. Then I add a personal layer for distro specifics and another one for BSP modifications. If I want to support multiples machines, I add corresponding vendor layer + personal BSP layer. I (jenkins jobs) only generate standard SDK for developers and they usually work only on one particular machine. Don't know if this helps.
– Nayfe
Mar 16 at 19:39
add a comment |
I never tried ext-sdk, but what I generally do is working directly with Yocto layers & recipes, withpoky,meta-openembeddedplus manufacturer layer, iemeta-intel. Then I add a personal layer for distro specifics and another one for BSP modifications. If I want to support multiples machines, I add corresponding vendor layer + personal BSP layer. I (jenkins jobs) only generate standard SDK for developers and they usually work only on one particular machine. Don't know if this helps.
– Nayfe
Mar 16 at 19:39
I never tried ext-sdk, but what I generally do is working directly with Yocto layers & recipes, with
poky, meta-openembedded plus manufacturer layer, ie meta-intel. Then I add a personal layer for distro specifics and another one for BSP modifications. If I want to support multiples machines, I add corresponding vendor layer + personal BSP layer. I (jenkins jobs) only generate standard SDK for developers and they usually work only on one particular machine. Don't know if this helps.– Nayfe
Mar 16 at 19:39
I never tried ext-sdk, but what I generally do is working directly with Yocto layers & recipes, with
poky, meta-openembedded plus manufacturer layer, ie meta-intel. Then I add a personal layer for distro specifics and another one for BSP modifications. If I want to support multiples machines, I add corresponding vendor layer + personal BSP layer. I (jenkins jobs) only generate standard SDK for developers and they usually work only on one particular machine. Don't know if this helps.– Nayfe
Mar 16 at 19:39
add a comment |
2 Answers
2
active
oldest
votes
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)
answered Mar 17 at 12:17
MartinMartin
7254 silver badges14 bronze badges
Thanks for this thorough answer... As a follow up, what built that which is checked out by the poky clone? Is there a set of meta-layers that the SDK could be applied to to generate that most functional poky clone? I mean what if I want that most functional poky clone for ARM? thanks
– Sam Liddicott
Mar 19 at 12:25
add a comment |
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
answered Mar 20 at 16:48
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55165986%2fwhy-cant-a-yocto-sdk-build-a-yocto-sdk%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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)
answered Mar 17 at 12:17
MartinMartin
7254 silver badges14 bronze badges
Thanks for this thorough answer... As a follow up, what built that which is checked out by the poky clone? Is there a set of meta-layers that the SDK could be applied to to generate that most functional poky clone? I mean what if I want that most functional poky clone for ARM? thanks
– Sam Liddicott
Mar 19 at 12:25
add a comment |
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)
answered Mar 17 at 12:17
MartinMartin
7254 silver badges14 bronze badges
Thanks for this thorough answer... As a follow up, what built that which is checked out by the poky clone? Is there a set of meta-layers that the SDK could be applied to to generate that most functional poky clone? I mean what if I want that most functional poky clone for ARM? thanks
– Sam Liddicott
Mar 19 at 12:25
add a comment |
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)
answered Mar 17 at 12:17
MartinMartin
7254 silver badges14 bronze badges
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)
answered Mar 17 at 12:17
MartinMartin
7254 silver badges14 bronze badges
answered Mar 17 at 12:17
MartinMartin
7254 silver badges14 bronze badges
answered Mar 17 at 12:17
MartinMartin
7254 silver badges14 bronze badges
answered Mar 17 at 12:17
MartinMartin
7254 silver badges14 bronze badges
7254 silver badges14 bronze badges
Thanks for this thorough answer... As a follow up, what built that which is checked out by the poky clone? Is there a set of meta-layers that the SDK could be applied to to generate that most functional poky clone? I mean what if I want that most functional poky clone for ARM? thanks
– Sam Liddicott
Mar 19 at 12:25
add a comment |
Thanks for this thorough answer... As a follow up, what built that which is checked out by the poky clone? Is there a set of meta-layers that the SDK could be applied to to generate that most functional poky clone? I mean what if I want that most functional poky clone for ARM? thanks
– Sam Liddicott
Mar 19 at 12:25
Thanks for this thorough answer... As a follow up, what built that which is checked out by the poky clone? Is there a set of meta-layers that the SDK could be applied to to generate that most functional poky clone? I mean what if I want that most functional poky clone for ARM? thanks
– Sam Liddicott
Mar 19 at 12:25
Thanks for this thorough answer... As a follow up, what built that which is checked out by the poky clone? Is there a set of meta-layers that the SDK could be applied to to generate that most functional poky clone? I mean what if I want that most functional poky clone for ARM? thanks
– Sam Liddicott
Mar 19 at 12:25
add a comment |
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
answered Mar 20 at 16:48
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
add a comment |
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
answered Mar 20 at 16:48
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
add a comment |
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
answered Mar 20 at 16:48
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
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
answered Mar 20 at 16:48
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
edited Mar 27 at 15:25
answered Mar 20 at 16:48
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
answered Mar 20 at 16:48
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
answered Mar 20 at 16:48
Sam LiddicottSam Liddicott
5693 silver badges15 bronze badges
5693 silver badges15 bronze badges
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55165986%2fwhy-cant-a-yocto-sdk-build-a-yocto-sdk%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I never tried ext-sdk, but what I generally do is working directly with Yocto layers & recipes, with
poky,meta-openembeddedplus manufacturer layer, iemeta-intel. Then I add a personal layer for distro specifics and another one for BSP modifications. If I want to support multiples machines, I add corresponding vendor layer + personal BSP layer. I (jenkins jobs) only generate standard SDK for developers and they usually work only on one particular machine. Don't know if this helps.– Nayfe
Mar 16 at 19:39