On 05/26/2015 03:38 PM, Ash Charles wrote:
On Tue, May 26, 2015 at 3:18 PM, Randy Witt
<randy.e.w...@linux.intel.com> wrote:
Did you source the environment-setup script? If so, what distro were you
using?
Ubuntu 15.04 (Vivid-Vervet). I used an SDK created based on the
gumstix-console-image rather than a mainstream image from meta-yocto
so perhaps there is a particular configuration etc. that messes up the
creation of the SDK?
<snip>
We were thinking it wouldn't be so granular Basically it would end up
matching everything in a manifest rather than asking for one particular
package. So it would look more like "devtool publish-sdk location", followed
by users being able to then update to whatever "sdk's" exist at that
location.
Okay---If I understand correctly, that's a little more limiting than I
would like. No matter how many different SDKs I provide, each
customer will need a different set of a software packages in their
sysroot. Yocto makes it easy to build up a big sstate or package
repository and post this online---users can just grab a baseline SDK
and then pull in the pieces they need (which probably is pretty
comfortable for folks who are used to a 'sudo apt-get install
libboost-dev' etc.).
Based on this, should I be turning my attention back to using smart
install with a regular SDK environment or is this imagined workflow
just not a reasonable objective?
It is a bit of a different workflow than we were initially looking at, but I
don't see a reason we couldn't do it. The locked signatures file should be able
to be a superset of items you would want, so theoretically if you only wanted
items from your sstate mirror to be used, the manifest would contain all items
on the mirror. This would prevent the user from building something locally
rather than pulling from the mirror and potentially not matching.
The nativesdk items are not in the extensible sdk, and the native items are just
part of the bitbake workspace. This is why it should be fairly easy to add what
you want. Because in the end it would just be adding an sstate mirror and doing
a bitbake "native-foo". And we could wrap that with devtool or some other command.
I do see the convenience and why you want it, so I'll talk it over with Paul
tomorrow.
Thanks,
--Ash
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
