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

[Martin Jansa]

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

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

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com