[OE-core] on current linux distros, what are potential candidates for ASSUME_PROVIDED?
Stephen Arnold
stephen.arnold42 at gmail.com
Thu Feb 26 19:03:50 UTC 2015
I would agree that for classroom purposes, some of the best time savers are
things like pre-fetching downloads to a local machine, pre-cloning kernel
repos, and shared cache.
Also, IIRC several of the course lab examples (in the LF Yocto course)
didn't quite work as expected (mostly kernel variables for some reason). I
would probably recommend keeping things simple, as in teaching the config
fragment approach (as is done in the kernel lab training thing). Can't
remember what the all the issues were exactly as I normally build off
master which gives me recurring deja vu, but keeping course materials
current is always an ongoing issue for me...
Just my $.02 ...
Steve
On Wed, Feb 25, 2015 at 12:41 AM, Robert P. J. Day <rpjday at crashcourse.ca>
wrote:
> On Wed, 25 Feb 2015, Richard Purdie wrote:
>
> > On Wed, 2015-02-25 at 03:25 -0500, Robert P. J. Day wrote:
> > > for the sake of reducing build time in the classroom, what are some
> > > of the potential (and relatively safe) candidates to add to
> > > ASSUME_PROVIDED for a build from scratch?
> >
> > This path is fraught with danger to be honest. There are some things
> > which are "safe" like subversion and git but they don't make that much
> > difference to a build and there are not as many as you'd think.
> >
> > The biggest difference you can make is an sstate cache you share amongst
> > the pupils. The time is spent:
> >
> > a) building gcc
> > b) building libc
> > c) building gettext
> > d) building glib
> >
> > each of these is a bottle neck which then opens up a new set of targets
> > as none of them are ASSUME_PROVIDED material.
>
> ok, fair enough.
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
> ========================================================================
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150226/e6a5ae8a/attachment-0002.html>
More information about the Openembedded-core
mailing list