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

[Barros Pena, Belen]

Thanks for the reply, Paul.

On 01/08/2016 09:13, "Paul Eggleton" <paul.eggleton at linux.intel.com> wrote:

>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.

This is a fair point. I will see how we can be clear about which SDK we
are exposing for those in the know, without confusing those blissfully
oblivious to the fact that we have 2 SDKs.

For the record: I disagree with keeping both, but that is a discussion for
some other time ;)

>
>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.

Yes: this has been on my to do list for a while. Exposing the cleaning
tasks, for example, might make sense. I'll see what we can do.

>
>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.

I see: so, would it be enough to add a text field for the "push to" path,
and a password field for the SSH case?

FWIW: although this makes sense when you explain it, I didn't quite get it
from the content of the manual

http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html#sdk-providi
ng-updates-after-installing-the-extensible-sdk

>
>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.

I can add that too. Is the variable documented anywhere?

>
>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.

I agree, as long as this doesn't become a barrier to implement the feature
("because we don't know how to do it properly, we don't do it" kind of
thing). I guess my question is: if we don't pull the declarations from the
metadata, from where then? Do you have anything in mind?

Thanks!

Belén

>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