any compelling reason to use SDK rather than eSDK?


Robert P. J. Day
 

colleague wants to get into working with SDKs, and as i'm just
diving into the intricacies of that myself, i'm not sure how to
answser the question: "is there any reason to use the regular SDK as
opposed to the extensible SDK?"

superficially, it would seem that the eSDK has nothing but benefits,
so other than perhaps needing more resources, is there any reason to
use the regular SDK and forego the benefits of eSDK?

rday


Quentin Schulz
 

Hi,

On Fri, Apr 30, 2021 at 05:49:29AM -0400, Robert P. J. Day wrote:

colleague wants to get into working with SDKs, and as i'm just
diving into the intricacies of that myself, i'm not sure how to
answser the question: "is there any reason to use the regular SDK as
opposed to the extensible SDK?"

superficially, it would seem that the eSDK has nothing but benefits,
It's very big and probably include your proprietary SW header and
libraries at the very least... or third party prebuilt
binaries/libraries you're not supposed to share outside of your product.

This is useful if you're doing active development internally and you
don't upgrade your Yocto layers too often. This means non-Yocto verse
people could work on the main SW stack without caring about Yocto at
all.

so other than perhaps needing more resources, is there any reason to
use the regular SDK and forego the benefits of eSDK?
Normal SDK is just a toolchain, very practical if a third party vendor
requires you to send them something so they can build a blob that works
on your machine. And usually, you don't want to send anything that is
remotely critical to your business, IP wise.

I have barely used SDK, so to be taken with a grain of salt as usual.

Cheers,
Quentin