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@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 -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
