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

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

[Graham Gower]

 * Point configure at where it can find jpeg.
 * Explicitly disable cdk and aalib.
 * Fix license while here.

Signed-off-by: Graham Gower <graham.gower@gmail.com>
---
 recipes/gphoto2/gphoto2_2.4.8.bb |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/recipes/gphoto2/gphoto2_2.4.8.bb b/recipes/gphoto2/gphoto2_2.4.8.bb
index ea54713..836ea85 100644
--- a/recipes/gphoto2/gphoto2_2.4.8.bb
+++ b/recipes/gphoto2/gphoto2_2.4.8.bb
@@ -1,7 +1,8 @@
 DESCRIPTION = "gphoto2 is a command-line utility to fetch pictures from digital cameras"
 SECTION = "console/utils"
-LICENSE = "GPL"
-DEPENDS = "libtool libgphoto2 popt"
+LICENSE = "GPLv2+"
+DEPENDS = "libtool libgphoto2 popt jpeg"
+PR = "r1"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/gphoto/gphoto2-${PV}.tar.bz2;name=gphoto2 \
            file://gphoto-popt-fixup.patch"
@@ -11,6 +12,10 @@ SRC_URI[gphoto2.sha256sum] = "a2e2f70fd6051234cbc3d76dc82df6991e8a07ead56aa8d5c4
 
 inherit autotools
 
+EXTRA_OECONF="--without-cdk \
+		--without-aalib \
+		--with-jpeg-prefix=${STAGING_EXECPREFIXDIR}"
+
 do_configure_append() {
         find ${S} -name Makefile | xargs sed -i 's:/usr/include:${STAGING_INCDIR}:'
 }
-- 
1.7.1

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

[Frans Meulenbroeks]

2010/11/2 Graham Gower <graham.gower@gmail.com>:
>  * Point configure at where it can find jpeg.
>  * Explicitly disable cdk and aalib.
>  * Fix license while here.
>
> Signed-off-by: Graham Gower <graham.gower@gmail.com>
> ---
>  recipes/gphoto2/gphoto2_2.4.8.bb |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/recipes/gphoto2/gphoto2_2.4.8.bb b/recipes/gphoto2/gphoto2_2.4.8.bb
> index ea54713..836ea85 100644
> --- a/recipes/gphoto2/gphoto2_2.4.8.bb
> +++ b/recipes/gphoto2/gphoto2_2.4.8.bb
> @@ -1,7 +1,8 @@
>  DESCRIPTION = "gphoto2 is a command-line utility to fetch pictures from digital cameras"
>  SECTION = "console/utils"
> -LICENSE = "GPL"
> -DEPENDS = "libtool libgphoto2 popt"
> +LICENSE = "GPLv2+"
> +DEPENDS = "libtool libgphoto2 popt jpeg"

The original recipe would build without the depends on jpeg
adding it to depends should be mentioned in the commit message

> +PR = "r1"
>
>  SRC_URI = "${SOURCEFORGE_MIRROR}/gphoto/gphoto2-${PV}.tar.bz2;name=gphoto2 \
>            file://gphoto-popt-fixup.patch"
> @@ -11,6 +12,10 @@ SRC_URI[gphoto2.sha256sum] = "a2e2f70fd6051234cbc3d76dc82df6991e8a07ead56aa8d5c4
>
>  inherit autotools
>
> +EXTRA_OECONF="--without-cdk \
> +               --without-aalib \
> +               --with-jpeg-prefix=${STAGING_EXECPREFIXDIR}"
> +

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.

from --help:

Optional Features:
  --disable-option-checking  ignore unrecognized --enable/--with options
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --disable-dependency-tracking  speeds up one-time build
  --enable-dependency-tracking   do not reject slow dependency extractors
  --enable-shared[=PKGS]  build shared libraries [default=yes]
  --enable-static[=PKGS]  build static libraries [default=yes]
  --enable-fast-install[=PKGS]
                          optimize for fast installation [default=yes]
  --disable-libtool-lock  avoid locking (might break parallel builds)
  --disable-largefile     omit support for large files
  --disable-nls           do not use Native Language Support
  --disable-rpath         do not hardcode runtime library paths

Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-pic              try to use only PIC/non-PIC objects [default=use
                          both]
  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
  --with-gnu-ld           assume the C compiler uses GNU ld default=no
  --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
  --without-libiconv-prefix     don't search for libiconv in
includedir and libdir
  --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
  --without-libintl-prefix     don't search for libintl in includedir and libdir
  --with-libgphoto2=PREFIX
                          where to find libgphoto2, "no" or "auto"
  --without-pthread         Don't use pthread
  --without-cdk           Do not use cdk
  --with-cdk-prefix=PREFIX
                          Location of cdk
  --without-jpeg          Do not use jpeg
  --with-jpeg-prefix=PREFIX
                          Location of jpeg
  --with-libexif=PREFIX   where to find libexif, "no" or "auto"
  --without-aalib         Do not use aalib
  --without-readline      Do not use readline

All things that are not mentioned in DEPENDS should (IMHO) be
explicitly be turned off.
And for the things in DEPENDS I would encourage to still add them.
E.g. --with-jpeg. Yes I know these will always be picked up when a
DEPENDS = "jpeg" is present, but making it explict does not hurt and
it trips an error if jpeg is not there and someone does a bitbake -b
of the recipe (instead of silently building a package without jpeg).

Thanks for your contribution & apologies for using your commit for a
rant on configure flags.

Frans.

>  do_configure_append() {
>         find ${S} -name Makefile | xargs sed -i 's:/usr/include:${STAGING_INCDIR}:'
>  }
> --
> 1.7.1
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Khem Raj]

On Mon, Nov 1, 2010 at 11:38 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/11/2 Graham Gower <graham.gower@gmail.com>:
>>  * Point configure at where it can find jpeg.
>>  * Explicitly disable cdk and aalib.
>>  * Fix license while here.
>>
>> Signed-off-by: Graham Gower <graham.gower@gmail.com>
>> ---
>>  recipes/gphoto2/gphoto2_2.4.8.bb |    9 +++++++--
>>  1 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/recipes/gphoto2/gphoto2_2.4.8.bb b/recipes/gphoto2/gphoto2_2.4.8.bb
>> index ea54713..836ea85 100644
>> --- a/recipes/gphoto2/gphoto2_2.4.8.bb
>> +++ b/recipes/gphoto2/gphoto2_2.4.8.bb
>> @@ -1,7 +1,8 @@
>>  DESCRIPTION = "gphoto2 is a command-line utility to fetch pictures from digital cameras"
>>  SECTION = "console/utils"
>> -LICENSE = "GPL"
>> -DEPENDS = "libtool libgphoto2 popt"
>> +LICENSE = "GPLv2+"
>> +DEPENDS = "libtool libgphoto2 popt jpeg"
>
> The original recipe would build without the depends on jpeg
> adding it to depends should be mentioned in the commit message
>
>> +PR = "r1"
>>
>>  SRC_URI = "${SOURCEFORGE_MIRROR}/gphoto/gphoto2-${PV}.tar.bz2;name=gphoto2 \
>>            file://gphoto-popt-fixup.patch"
>> @@ -11,6 +12,10 @@ SRC_URI[gphoto2.sha256sum] = "a2e2f70fd6051234cbc3d76dc82df6991e8a07ead56aa8d5c4
>>
>>  inherit autotools
>>
>> +EXTRA_OECONF="--without-cdk \
>> +               --without-aalib \
>> +               --with-jpeg-prefix=${STAGING_EXECPREFIXDIR}"
>> +
>
> 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.

Thx
-Khem

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

[Graham Gower]

On 2 November 2010 17:08, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/11/2 Graham Gower <graham.gower@gmail.com>:
>>  * Point configure at where it can find jpeg.
>>  * Explicitly disable cdk and aalib.
>>  * Fix license while here.
>>
>> Signed-off-by: Graham Gower <graham.gower@gmail.com>
>> ---
>>  recipes/gphoto2/gphoto2_2.4.8.bb |    9 +++++++--
>>  1 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/recipes/gphoto2/gphoto2_2.4.8.bb b/recipes/gphoto2/gphoto2_2.4.8.bb
>> index ea54713..836ea85 100644
>> --- a/recipes/gphoto2/gphoto2_2.4.8.bb
>> +++ b/recipes/gphoto2/gphoto2_2.4.8.bb
>> @@ -1,7 +1,8 @@
>>  DESCRIPTION = "gphoto2 is a command-line utility to fetch pictures from digital cameras"
>>  SECTION = "console/utils"
>> -LICENSE = "GPL"
>> -DEPENDS = "libtool libgphoto2 popt"
>> +LICENSE = "GPLv2+"
>> +DEPENDS = "libtool libgphoto2 popt jpeg"
>
> The original recipe would build without the depends on jpeg
> adding it to depends should be mentioned in the commit message
>
>> +PR = "r1"
>>
>>  SRC_URI = "${SOURCEFORGE_MIRROR}/gphoto/gphoto2-${PV}.tar.bz2;name=gphoto2 \
>>            file://gphoto-popt-fixup.patch"
>> @@ -11,6 +12,10 @@ SRC_URI[gphoto2.sha256sum] = "a2e2f70fd6051234cbc3d76dc82df6991e8a07ead56aa8d5c4
>>
>>  inherit autotools
>>
>> +EXTRA_OECONF="--without-cdk \
>> +               --without-aalib \
>> +               --with-jpeg-prefix=${STAGING_EXECPREFIXDIR}"
>> +
>
> 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.
>
> from --help:
>
> Optional Features:
>  --disable-option-checking  ignore unrecognized --enable/--with options
>  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
>  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
>  --disable-dependency-tracking  speeds up one-time build
>  --enable-dependency-tracking   do not reject slow dependency extractors
>  --enable-shared[=PKGS]  build shared libraries [default=yes]
>  --enable-static[=PKGS]  build static libraries [default=yes]
>  --enable-fast-install[=PKGS]
>                          optimize for fast installation [default=yes]
>  --disable-libtool-lock  avoid locking (might break parallel builds)
>  --disable-largefile     omit support for large files
>  --disable-nls           do not use Native Language Support
>  --disable-rpath         do not hardcode runtime library paths
>
> Optional Packages:
>  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
>  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
>  --with-pic              try to use only PIC/non-PIC objects [default=use
>                          both]
>  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
>  --with-gnu-ld           assume the C compiler uses GNU ld default=no
>  --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
>  --without-libiconv-prefix     don't search for libiconv in
> includedir and libdir
>  --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
>  --without-libintl-prefix     don't search for libintl in includedir and libdir
>  --with-libgphoto2=PREFIX
>                          where to find libgphoto2, "no" or "auto"
>  --without-pthread         Don't use pthread
>  --without-cdk           Do not use cdk
>  --with-cdk-prefix=PREFIX
>                          Location of cdk
>  --without-jpeg          Do not use jpeg
>  --with-jpeg-prefix=PREFIX
>                          Location of jpeg
>  --with-libexif=PREFIX   where to find libexif, "no" or "auto"
>  --without-aalib         Do not use aalib
>  --without-readline      Do not use readline
>
> All things that are not mentioned in DEPENDS should (IMHO) be
> explicitly be turned off.
> And for the things in DEPENDS I would encourage to still add them.
> E.g. --with-jpeg. Yes I know these will always be picked up when a
> DEPENDS = "jpeg" is present, but making it explict does not hurt and
> it trips an error if jpeg is not there and someone does a bitbake -b
> of the recipe (instead of silently building a package without jpeg).
>
> Thanks for your contribution & apologies for using your commit for a
> rant on configure flags.
>
> Frans.
>

I agree with you here. Often a recipe breaks when a particular
subsystem is enabled, which is usually not enabled during regular
image builds. And it can be difficult to determine if something should
be added to DEPENDS or disabled at configure time.

What I found with gphoto2 (which probably wasn't clear) was the
configure script was testing for jpeg and cdk with
-I/usr/local/include. So I guessed on what was useful and what wasn't
and added jpeg to depends to make it clear that jpeg support was
intended (even though it will likely be pulled in by other
dependencies).

I assume you just want exif and readline disabled too? (and possibly
an essay in the commit message :))

-Graham

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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03-11-10 01:04, Graham Gower wrote:
> On 2 November 2010 17:08, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2010/11/2 Graham Gower <graham.gower@gmail.com>:
>>>  * Point configure at where it can find jpeg.
>>>  * Explicitly disable cdk and aalib.
>>>  * Fix license while here.
>>>
>>> Signed-off-by: Graham Gower <graham.gower@gmail.com>
>>> ---
>>>  recipes/gphoto2/gphoto2_2.4.8.bb |    9 +++++++--
>>>  1 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/recipes/gphoto2/gphoto2_2.4.8.bb b/recipes/gphoto2/gphoto2_2.4.8.bb
>>> index ea54713..836ea85 100644
>>> --- a/recipes/gphoto2/gphoto2_2.4.8.bb
>>> +++ b/recipes/gphoto2/gphoto2_2.4.8.bb
>>> @@ -1,7 +1,8 @@
>>>  DESCRIPTION = "gphoto2 is a command-line utility to fetch pictures from digital cameras"
>>>  SECTION = "console/utils"
>>> -LICENSE = "GPL"
>>> -DEPENDS = "libtool libgphoto2 popt"
>>> +LICENSE = "GPLv2+"
>>> +DEPENDS = "libtool libgphoto2 popt jpeg"
>>
>> The original recipe would build without the depends on jpeg
>> adding it to depends should be mentioned in the commit message
>>
>>> +PR = "r1"
>>>
>>>  SRC_URI = "${SOURCEFORGE_MIRROR}/gphoto/gphoto2-${PV}.tar.bz2;name=gphoto2 \
>>>            file://gphoto-popt-fixup.patch"
>>> @@ -11,6 +12,10 @@ SRC_URI[gphoto2.sha256sum] = "a2e2f70fd6051234cbc3d76dc82df6991e8a07ead56aa8d5c4
>>>
>>>  inherit autotools
>>>
>>> +EXTRA_OECONF="--without-cdk \
>>> +               --without-aalib \
>>> +               --with-jpeg-prefix=${STAGING_EXECPREFIXDIR}"
>>> +
>>
>> 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.
>>
>> from --help:
>>
>> Optional Features:
>>  --disable-option-checking  ignore unrecognized --enable/--with options
>>  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
>>  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
>>  --disable-dependency-tracking  speeds up one-time build
>>  --enable-dependency-tracking   do not reject slow dependency extractors
>>  --enable-shared[=PKGS]  build shared libraries [default=yes]
>>  --enable-static[=PKGS]  build static libraries [default=yes]
>>  --enable-fast-install[=PKGS]
>>                          optimize for fast installation [default=yes]
>>  --disable-libtool-lock  avoid locking (might break parallel builds)
>>  --disable-largefile     omit support for large files
>>  --disable-nls           do not use Native Language Support
>>  --disable-rpath         do not hardcode runtime library paths
>>
>> Optional Packages:
>>  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
>>  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
>>  --with-pic              try to use only PIC/non-PIC objects [default=use
>>                          both]
>>  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
>>  --with-gnu-ld           assume the C compiler uses GNU ld default=no
>>  --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
>>  --without-libiconv-prefix     don't search for libiconv in
>> includedir and libdir
>>  --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
>>  --without-libintl-prefix     don't search for libintl in includedir and libdir
>>  --with-libgphoto2=PREFIX
>>                          where to find libgphoto2, "no" or "auto"
>>  --without-pthread         Don't use pthread
>>  --without-cdk           Do not use cdk
>>  --with-cdk-prefix=PREFIX
>>                          Location of cdk
>>  --without-jpeg          Do not use jpeg
>>  --with-jpeg-prefix=PREFIX
>>                          Location of jpeg
>>  --with-libexif=PREFIX   where to find libexif, "no" or "auto"
>>  --without-aalib         Do not use aalib
>>  --without-readline      Do not use readline
>>
>> All things that are not mentioned in DEPENDS should (IMHO) be
>> explicitly be turned off.
>> And for the things in DEPENDS I would encourage to still add them.
>> E.g. --with-jpeg. Yes I know these will always be picked up when a
>> DEPENDS = "jpeg" is present, but making it explict does not hurt and
>> it trips an error if jpeg is not there and someone does a bitbake -b
>> of the recipe (instead of silently building a package without jpeg).
>>
>> Thanks for your contribution & apologies for using your commit for a
>> rant on configure flags.
>>
>> Frans.
>>
> 
> I agree with you here. Often a recipe breaks when a particular
> subsystem is enabled, which is usually not enabled during regular
> image builds. And it can be difficult to determine if something should
> be added to DEPENDS or disabled at configure time.
> 
> What I found with gphoto2 (which probably wasn't clear) was the
> configure script was testing for jpeg and cdk with
> -I/usr/local/include. So I guessed on what was useful and what wasn't
> and added jpeg to depends to make it clear that jpeg support was
> intended (even though it will likely be pulled in by other
> dependencies).
> 
> I assume you just want exif and readline disabled too? (and possibly
> an essay in the commit message :))

For gphoto2 to be usefull it need exif, not sure what readline brings us.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFM0RX/MkyGM64RGpERApdsAJ0UwmJ03Z/Q7LyJoSKssYWZQRg1wQCeL94P
FIJjFYYigRNPTPrV1XXemD8=
=GDK5
-----END PGP SIGNATURE-----

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

[Frans Meulenbroeks]

2010/11/2 Khem Raj <raj.khem@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.

Wrt exif & readline: I agree with koen.

Frans.

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

[Khem Raj]

On Wed, Nov 3, 2010 at 2:42 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/11/2 Khem Raj <raj.khem@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.

> Wrt exif & readline: I agree with koen.
>
> Frans.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Andrea Adami]

I think the most elegant solution comes from something like USE flags.

See  http://gentoo-portage.com/media-gfx/gphoto2  (2_2.4.9 fwiw)

...
IUSE="aalib exif ncurses nls readline"
...
exif? (	media-libs/libexif )
readline? ( sys-libs/readline )
...

Drawback is each recipe needs to be edited.

My 2 Cents

Andrea

Re: [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@gmail.com> wrote:
> > 2010/11/2 Khem Raj <raj.khem@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@gmail.com

Re: [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@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@gmail.com> wrote:
>> > 2010/11/2 Khem Raj <raj.khem@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@gmail.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Frans Meulenbroeks]

2010/11/3 Khem Raj <raj.khem@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).

Frans

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

[Khem Raj]

On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/11/3 Khem Raj <raj.khem@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.

> Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Frans Meulenbroeks]

2010/11/3 Khem Raj <raj.khem@gmail.com>:
> On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2010/11/3 Khem Raj <raj.khem@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.
One way to get a minimal package is to have everything in packaged
staging then bake the recipe.
that'll only drag in stuff from depends.

Frans

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

[Khem Raj]

On Wed, Nov 3, 2010 at 1:21 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/11/3 Khem Raj <raj.khem@gmail.com>:
>> On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>>> 2010/11/3 Khem Raj <raj.khem@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 ?

> One way to get a minimal package is to have everything in packaged
> staging then bake the recipe.
> that'll only drag in stuff from depends.

It depends also on the sequence of staging. So there are multiple
factors and no two stagings will look same


>
> Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Frans Meulenbroeks]

2010/11/3 Khem Raj <raj.khem@gmail.com>:
> On Wed, Nov 3, 2010 at 1:21 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2010/11/3 Khem Raj <raj.khem@gmail.com>:
>>> On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks
>>> <fransmeulenbroeks@gmail.com> wrote:
>>>> 2010/11/3 Khem Raj <raj.khem@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

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

[Khem Raj]

On Fri, Nov 5, 2010 at 12:51 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/11/3 Khem Raj <raj.khem@gmail.com>:
>> On Wed, Nov 3, 2010 at 1:21 PM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>>> 2010/11/3 Khem Raj <raj.khem@gmail.com>:
>>>> On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks
>>>> <fransmeulenbroeks@gmail.com> wrote:
>>>>> 2010/11/3 Khem Raj <raj.khem@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.

> Enjoy! Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Frans Meulenbroeks]

2010/11/5 Khem Raj <raj.khem@gmail.com>:
> On Fri, Nov 5, 2010 at 12:51 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2010/11/3 Khem Raj <raj.khem@gmail.com>:
>>> On Wed, Nov 3, 2010 at 1:21 PM, Frans Meulenbroeks
>>> <fransmeulenbroeks@gmail.com> wrote:
>>>> 2010/11/3 Khem Raj <raj.khem@gmail.com>:
>>>>> On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks
>>>>> <fransmeulenbroeks@gmail.com> wrote:
>>>>>> 2010/11/3 Khem Raj <raj.khem@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