[poky] Native vs not
Richard Purdie
richard.purdie at linuxfoundation.org
Mon Mar 14 10:55:26 PDT 2011
On Mon, 2011-03-14 at 10:46 -0700, Tom Rini wrote:
> On 03/14/2011 10:40 AM, Richard Purdie wrote:
> > On Mon, 2011-03-14 at 10:26 -0700, Tom Rini wrote:
> >> On 03/11/2011 05:10 PM, Khem Raj wrote:
> >>
> >>> I think having some buildhost/native packages (based on distro/version) trusted and assume provided or even
> >>> installed using the build host package management could be one approach
> >>> in modern distros I think we could use lot of host packages as is. or
> >>> may be trust all and keep a list of blacklisted packages for a given
> >>> distro might be something useful
> >>
> >> I've been thinking about this a bit and at least at the high level there
> >> is an argument for making it easy to opt out of a big class of host
> >> tools, on a modern distro and trade reprodicibility / reliability for
> >> faster initial build times. And on the flip side, opt out of a bit more
> >> of our host tool dependencies.
> >
> > This is what ASSUME_PROVIDED is there for :)
>
> Well yes. But it'd be nice if we had a few helpers so you could say:
> ASSUME_PROVIDED += "${SCM_FETCH_TOOLS} ${DOCUMENTATION_GENERATION_TOOLS}
> ..."
> and so forth.
We need to user to be very clearly aware of what they're adding IMO so
I'd prefer maybe just some commented out lines such as:
# Uncomment this if you want to use the system provided scm utilities
# instead of having the system build them
#ASSUME_PROVIDED += "git-native svn-native"
I'm actually thinking about a local.conf.sample.advanced file where we
list a load of things like this. This means we can keep
local.conf.sample simple (the things they probably *need* to look at)
yet still show users some of the other more advanced options.
Cheers,
Richard
More information about the poky
mailing list