[Toaster] Design - Building and configuring the eSDK with Toaster

[Paul Eggleton]

Hi Belen,

On Fri, 29 Jul 2016 11:27:37 Barros Pena, Belen wrote:
> Related to this Bugzilla entry
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9297
> 
> I have an initial proposal on how to build and configure the extensible
> SDK with Toaster
> 
> https://youtu.be/NH2T3lebh8A
> 
> Feedback, comments and questions sorely needed (this is just v1 and might
> have some glaring errors or gaps).

Thanks for producing this. It looks fairly reasonable, some things to consider 
though:

1) It's not clear to me when the eSDK will replace the standard SDK - at least 
in 2.2 it will finally be possible for that to happen, but because the eSDK is 
still a bit larger than the standard SDK I suspect some people who just want 
the basic toolchain will want to stick with the standard SDK for a while yet. 
For that reason I think it would make sense if the UI was clear about what 
kind of SDK it's building.

2) Following on from that, I know it complicates matters but I think we may 
want to consider how we would present alternative tasks than just "SDK" (that 
maps to do_populate_sdk_ext) and "Build" buttons - there are likely to be 
other tasks of interest here including do_populate_sdk. Admittedly it's less 
about how this particular functionality works and more about how we might make 
those other tasks more obviously available in future.

3) The update URL isn't all that you need to publish the SDK - the URL is (at 
least assumed to be) read-only, i.e. it's what the installed SDK pulls from, 
not what oe-publish-sdk can push to. In order to work, oe-publish-sdk needs a 
local directory path or alternatively user at host:/path to use SSH, but if using 
the latter the user may also be prompted for a password if they aren't using 
key-based authentication. As you might gather there's an element of the local 
vs. server installation problem creeping in here that we've hit elsewhere.

4) FYI we've just introduced an additional variable SDK_INCLUDE_TOOLCHAIN, 
which within the build system defaults to "1" if SDK_EXT_TYPE is "full" or "0" 
if it's "minimal", so the UI will need to do the same.

5) In terms of implementation, since this UI is based around the variables I 
really think we should define the UI declaratively rather than by hardcoding 
the knowledge into the UI. Whether we actually pull those declarations from 
the metadata is a separate issue (and not currently practical given this UI 
has to be available before running any builds), but we should start along the 
right course from the beginning. This is mostly a note for whoever implements 
it, but it may have minor implications on how the UI works as well.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre