[poky] Native vs not

[Gary Thomas]

On 03/14/2011 12:03 PM, Tom Rini wrote:
> 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).

I fully agree with the basic idea, but I'm not sure it solves everything.
I ended up down this road when a configure step tried to use a host tool,
in this case /usr/bin/rsvg-convert.  I think there still would have been
some grousing even if I had ASSUME_PROVIDED="librsvg-native" which is
the package I ended up needing to build.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------