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

[Paul Eggleton]

On Mon, 01 Aug 2016 10:01:14 Barros Pena, Belen wrote:
> On 01/08/2016 09:13, "Paul Eggleton" <paul.eggleton at linux.intel.com> wrote:
> >On Fri, 29 Jul 2016 11:27:37 Barros Pena, Belen wrote:
> >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 ;)

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

I think so yes. What I was alluding to is that this still may feel a bit 
awkward given that it's usually something you do locally rather than via a web 
browser, but we can see how it pans out.
 
> 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

OK, I'll see what I can do to clarify that.
 
> >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?

No, not yet - the code changes only just hit master, but it's on the todo 
list.
 
> >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?

What I meant was, you could still have them in the code, but define it as a 
structure where you have the fields you want to capture, and the rules that 
govern how they interact, such that those definitions could be pulled from the 
metadata at some point in future.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre