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

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Fri Nov 5 07:51:49 UTC 2010


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 ? )

Enjoy! Frans




More information about the Openembedded-devel mailing list