[oe] [PATCH] gphoto2_2.4.8.bb: Stop configure from looking in /usr/local/include

[Frans Meulenbroeks]

2010/11/5 Khem Raj <raj.khem at gmail.com>:
> On Fri, Nov 5, 2010 at 12:51 AM, Frans Meulenbroeks
> <fransmeulenbroeks at gmail.com> wrote:
>> 2010/11/3 Khem Raj <raj.khem at gmail.com>:
>>> On Wed, Nov 3, 2010 at 1:21 PM, Frans Meulenbroeks
>>> <fransmeulenbroeks at gmail.com> wrote:
>>>> 2010/11/3 Khem Raj <raj.khem at gmail.com>:
>>>>> On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks
>>>>> <fransmeulenbroeks at gmail.com> wrote:
>>>>>> 2010/11/3 Khem Raj <raj.khem at gmail.com>:
>>>>>>
>>>>>>>
>>>>>>> yes a more detailed solution is better. you have to go through the
>>>>>>> configure of every
>>>>>>> package and understand the behavior then act upon. As I said before
>>>>>>> its a tedious task
>>>>>>>
>>>>>> I'm well aware of this. That is also why in the infrastructure thread
>>>>>> I suggested using automated testing to find misbehaving packages.
>>>>>>
>>>>>> Btw there are 355 .inc files that contain the word autotools and 1899 .bb files.
>>>>>> Of course there are lots of dups in there.
>>>>>> And maybe for the base recipes we can convince the yocto people that
>>>>>> this is a serious QA issue (and they have some people employed to work
>>>>>> on this if I understood properly).
>>>>>>
>>>>>
>>>>> numbers means not so much when it comes down to this. I don't know if
>>>>> any distribution that even does that
>>>>> so I take comfort in everyone being wrong.
>>>>>
>>>>
>>>> I agree that numbers don't mean that much. Just wanted to give an
>>>> indication of the possible effort needed.
>>>> Also no idea how debian does this.
>>>
>>> Does it do it in first place ?
>>
>> I peeked briefly at the sources.
>> Debian seems to resolve the problem by going for the max dependencies
>> so autotools can pick up everything.
>> E.g. for gphoto2, lenny has a depends on both libexif and libreadline
>> (see http://packages.debian.org/lenny/gphoto2)
>> So basically they go for the max config.
>>
>> We could do the same. Then again for deeply embedded systems it might
>> be desirable to allow more finegrained tuning.
>> (did I hear someone say USE flags ? )
>>
>
> which is good for things that dont care about size. Not so good for
> embedded systems I think.
> and there are some packages I know which have catch-22 situation so
> adding max depends is
> also not a wholesome solution.
>

Catch22 situations seem mostly to appear because one packag exports
both a lib and a (sample) program.
One example that I saw recently was libcdio and libcddb.

Probably the only other way of catch 22 situations are triple or
quadruple staged builds.(build A, build B rebuild A maybe rebuild B)

Frans