Re: Native vs not

[Tom Rini <tom_rini@mentor.com>]

On 03/14/2011 10:55 AM, Richard Purdie wrote:
> 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.

I agree.  There's very real risk involved in not assuming things.  But 
there's also very real cases where people are fine taking the risk (and 
in some cases it's not really that risky, eg scm fetching tools, but 
others really are).

-- 
Tom Rini
Mentor Graphics Corporation