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

[Khem Raj]

On Wed, Nov 3, 2010 at 8:47 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
> On Wed, Nov 03, 2010 at 08:17:29AM -0700, Khem Raj wrote:
>> On Wed, Nov 3, 2010 at 2:42 AM, Frans Meulenbroeks
>> <fransmeulenbroeks at gmail.com> wrote:
>> > 2010/11/2 Khem Raj <raj.khem at gmail.com>:
>> >> On Mon, Nov 1, 2010 at 11:38 PM, Frans Meulenbroeks
>> >
>> >>> I have some concerns here.
>> >>> For configure it seems best to explicitly set and reset the flags in
>> >>> it, otherwise you may just pick up whatever happened to be build
>> >>> before.
>> >>>
>> >>
>> >>
>> >> this is the case with any package that uses configure tools. But assumption here
>> >> is that when you are building you are not building stuff thats not
>> >> meant to be in
>> >> the given image.
>> >
>> > True. However we should enforce that. If e.g. gphoto has no depends on
>> > exif it autotools will still pick up exif if it happens to be there
>> > because some other package build it.
>> > Funtionally this is not necessarily bad (as your image has exif
>> > anyway), but from a point of reproducability it is undesirable.
>> > E.g. if you build the recipe the first time, you might not get exif
>> > and if you rebuild you do get exif. (because the build system does not
>> > know the dependency is there so it might not have build exif yet).
>> >
>> > Actually the results might even differ for between builds of the same
>> > image (especially if you build machines with different speeds etc
>> > and/or use different flags for parallellism.
>> > Therefore I feel it is highly desirable to have all optionals that you
>> > have in configure either explicitly disabled or explicitly added to
>> > depends.
>> >
>>
>> this is everlasting problem with autoconf and autotools. There is a
>> set of options
>> which are enabled based on what autoconf guesses on the sysroots. Unfortunately
>> it will be very tedious if you want to explicitly enable and disable
>> every option as well.
>> and there are quite a lot of packages using autotools. However I think
>> that the sysroot is minimal
>> when we build from scratch so most of options should be disabled which
>> are decided by autoconf
>> so we may not get unneeded features which is better than having them
>> enabled at build time
>> and needed support being missing at run time.
>
> well but then you rebuild that package ie after just PR bump and feature
> gets enabled, users gets used to it and with next rebuild from scratch
> you will be surprised why they are complaining about missing feature
> (happened to me with python + tk).
>

yes there are many other packages including eglibc/glibc which will
not configured same on rebuild.

> So to keep them disabled even for next rebuild after PR bump we should
> put --disable-feature to EXTRA_OECONF to be sure.
>
> But that would make it conflicting for maintainers who are used to have it
> "usually enabled" and "usually disabled".
>
> Which can be solved by DISTRO_FEATURES but some shortcuts like gentoo
> has would be usefull
>
> DEPENDS += tk? ( >=dev-lang/tk-8.0 )
> instead of
> DEPENDS += ${@base_contains('DISTRO_FEATURES', 'tk', 'tk', '', d)}
>
> $(use_with threads)
> instead of
> ${@base_contains('DISTRO_FEATURES', 'threads', '--with-threads', --without-threads)}
>
> $(use_enable ipv6)
> instead of
> ${@base_contains('DISTRO_FEATURES', 'ipv6', '--enable-ipv6', --disable-ipv6)}
>
> or even
> DEPEND="dev-libs/ecore[evas]"
> instead of
> hoping that ecore was built with evas support
>

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


> Regards,
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>