Thanks for the reply, Paul. On 01/08/2016 09:13, "Paul Eggleton" <[email protected]> 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@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 -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
