Patch for libfann-2.0.0 recipe

Patch for libfann-2.0.0 recipe

[Elvis Dowson]

Hi,
	I'm attaching a patch for the libfann-2.0.0 recipe for inclusion into  
the oe repository.

Best regards,

Elvis

 From edb273d68849fd968f83a0bf59efba120b578fa3 Mon Sep 17 00:00:00 2001
From: Elvis Dowson <elvis.dowson@gmail.com>
Date: Tue, 16 Jun 2009 21:12:52 +0400
Subject: [PATCH] Added libfann-2.0.0 recipe

---
  conf/checksums.ini               |    4 ++++
  recipes/libfann/libfann_2.0.0.bb |   23 +++++++++++++++++++++++
  2 files changed, 27 insertions(+), 0 deletions(-)
  create mode 100644 recipes/libfann/libfann_2.0.0.bb

diff --git a/conf/checksums.ini b/conf/checksums.ini
index 37d55c7..7c38ea9 100644
--- a/conf/checksums.ini
+++ b/conf/checksums.ini
@@ -286,6 +286,10 @@  
sha256=1f8504c7f08d2d59c71a70915fc834a285b99587444ee33e23ee3f135c071da0
  md5=a8cf945d09c6458cb27228218e9a2f45
   
sha256=8416e162d6fc921f14a61c8905e9f9a28dc25e67e1c71b75574360a13f0c28c7

+[http://prdownloads.sourceforge.net/fann/fann-2.0.0.tar.bz2]
+md5=4224efa533265dcf39237667973d0e20
+sha256=762a1313a9b935300cb66ebf052d469d04823ca721fe6dd2a49c01e13e8ab30a
+
  [http://downloads.sourceforge.net/fordiac/FORTE-0.3.5.zip]
  md5=d207d3b389ee9f2702df095681459f99
   
sha256=2b87b331e931db2db07408c1b07bdb557227e0c16f8fe37f72e40b08fca0a09c
diff --git a/recipes/libfann/libfann_2.0.0.bb b/recipes/libfann/ 
libfann_2.0.0.bb
new file mode 100644
index 0000000..d3166ec
--- /dev/null
+++ b/recipes/libfann/libfann_2.0.0.bb
@@ -0,0 +1,23 @@
+# libfann-2.0.0 recipie
+SECTION = "libs"
+DEFAULT_PREFERENCE = "1"
+
+# Package information
+DESCRIPTION = "libfann, Fast Artificial Neural Network Library is a  
free open source neural network library, which implements multilayer  
artificial neural networks in C with support for both fully connected  
and sparsely connected networks."
+LICENSE = "BSD"
+PN = "libfann"
+PV = "2.0.0"
+PR = "r01"
+
+SRC_URI = "http://prdownloads.sourceforge.net/fann/fann-${PV}.tar.bz2"
+
+S = "${WORKDIR}/fann-${PV}"
+
+inherit autotools pkgconfig
+
+do_stage () {
+	oe_libinstall -a -so -C src libfann ${STAGING_LIBDIR}
+	install -d ${STAGING_INCDIR}/fann
+	(cd ${S}/src/include; cp compat_time.h config.h doublefann.h fann.h  
fann_activation.h fann_cascade.h fann_data.h fann_error.h  
fann_internal.h fann_io.h fann_train.h fixedfann.h floatfann.h $ 
{STAGING_INCDIR}/fann/)
+	install -m 0644 ${S}/aclocal.m4 ${STAGING_DATADIR}/aclocal/
+}
-- 
1.6.0.3

Re: Patch for libfann-2.0.0 recipe

[Koen Kooi]

On 16-06-09 19:14, Elvis Dowson wrote:
> Hi,
> I'm attaching a patch for the libfann-2.0.0 recipe for inclusion into
> the oe repository.
>
> Best regards,
>
> Elvis
>
>  From edb273d68849fd968f83a0bf59efba120b578fa3 Mon Sep 17 00:00:00 2001
> From: Elvis Dowson <elvis.dowson@gmail.com>
> Date: Tue, 16 Jun 2009 21:12:52 +0400
> Subject: [PATCH] Added libfann-2.0.0 recipe
>
> ---
> conf/checksums.ini | 4 ++++
> recipes/libfann/libfann_2.0.0.bb | 23 +++++++++++++++++++++++
> 2 files changed, 27 insertions(+), 0 deletions(-)
> create mode 100644 recipes/libfann/libfann_2.0.0.bb
>
> diff --git a/conf/checksums.ini b/conf/checksums.ini
> index 37d55c7..7c38ea9 100644
> --- a/conf/checksums.ini
> +++ b/conf/checksums.ini
> @@ -286,6 +286,10 @@
> sha256=1f8504c7f08d2d59c71a70915fc834a285b99587444ee33e23ee3f135c071da0
> md5=a8cf945d09c6458cb27228218e9a2f45
> sha256=8416e162d6fc921f14a61c8905e9f9a28dc25e67e1c71b75574360a13f0c28c7
>
> +[http://prdownloads.sourceforge.net/fann/fann-2.0.0.tar.bz2]
> +md5=4224efa533265dcf39237667973d0e20
> +sha256=762a1313a9b935300cb66ebf052d469d04823ca721fe6dd2a49c01e13e8ab30a
> +
> [http://downloads.sourceforge.net/fordiac/FORTE-0.3.5.zip]
> md5=d207d3b389ee9f2702df095681459f99
> sha256=2b87b331e931db2db07408c1b07bdb557227e0c16f8fe37f72e40b08fca0a09c
> diff --git a/recipes/libfann/libfann_2.0.0.bb
> b/recipes/libfann/libfann_2.0.0.bb
> new file mode 100644
> index 0000000..d3166ec
> --- /dev/null
> +++ b/recipes/libfann/libfann_2.0.0.bb
> @@ -0,0 +1,23 @@
> +# libfann-2.0.0 recipie
> +SECTION = "libs"
> +DEFAULT_PREFERENCE = "1"
> +
> +# Package information
> +DESCRIPTION = "libfann, Fast Artificial Neural Network Library is a
> free open source neural network library, which implements multilayer
> artificial neural networks in C with support for both fully connected
> and sparsely connected networks."
> +LICENSE = "BSD"
> +PN = "libfann"
> +PV = "2.0.0"
> +PR = "r01"
> +
> +SRC_URI = "http://prdownloads.sourceforge.net/fann/fann-${PV}.tar.bz2"
> +
> +S = "${WORKDIR}/fann-${PV}"
> +
> +inherit autotools pkgconfig
> +
> +do_stage () {
> + oe_libinstall -a -so -C src libfann ${STAGING_LIBDIR}
> + install -d ${STAGING_INCDIR}/fann
> + (cd ${S}/src/include; cp compat_time.h config.h doublefann.h fann.h
> fann_activation.h fann_cascade.h fann_data.h fann_error.h
> fann_internal.h fann_io.h fann_train.h fixedfann.h floatfann.h
> ${STAGING_INCDIR}/fann/)
> + install -m 0644 ${S}/aclocal.m4 ${STAGING_DATADIR}/aclocal/
> +}

Can't you use autotools_stage to stage all this? And if not, don't use 
'cp', but 'install'.

regards,

Koen

Re: Patch for libfann-2.0.0 recipe

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 2969 bytes --]

Koen Kooi wrote:
> On 16-06-09 19:14, Elvis Dowson wrote:
>> Hi,
>> I'm attaching a patch for the libfann-2.0.0 recipe for inclusion into
>> the oe repository.
>>
>> Best regards,
>>
>> Elvis
>>
>>  From edb273d68849fd968f83a0bf59efba120b578fa3 Mon Sep 17 00:00:00 2001
>> From: Elvis Dowson <elvis.dowson@gmail.com>
>> Date: Tue, 16 Jun 2009 21:12:52 +0400
>> Subject: [PATCH] Added libfann-2.0.0 recipe
>>
>> ---
>> conf/checksums.ini | 4 ++++
>> recipes/libfann/libfann_2.0.0.bb | 23 +++++++++++++++++++++++
>> 2 files changed, 27 insertions(+), 0 deletions(-)
>> create mode 100644 recipes/libfann/libfann_2.0.0.bb
>>
>> diff --git a/conf/checksums.ini b/conf/checksums.ini
>> index 37d55c7..7c38ea9 100644
>> --- a/conf/checksums.ini
>> +++ b/conf/checksums.ini
>> @@ -286,6 +286,10 @@
>> sha256=1f8504c7f08d2d59c71a70915fc834a285b99587444ee33e23ee3f135c071da0
>> md5=a8cf945d09c6458cb27228218e9a2f45
>> sha256=8416e162d6fc921f14a61c8905e9f9a28dc25e67e1c71b75574360a13f0c28c7
>>
>> +[http://prdownloads.sourceforge.net/fann/fann-2.0.0.tar.bz2]
>> +md5=4224efa533265dcf39237667973d0e20
>> +sha256=762a1313a9b935300cb66ebf052d469d04823ca721fe6dd2a49c01e13e8ab30a
>> +
>> [http://downloads.sourceforge.net/fordiac/FORTE-0.3.5.zip]
>> md5=d207d3b389ee9f2702df095681459f99
>> sha256=2b87b331e931db2db07408c1b07bdb557227e0c16f8fe37f72e40b08fca0a09c
>> diff --git a/recipes/libfann/libfann_2.0.0.bb
>> b/recipes/libfann/libfann_2.0.0.bb
>> new file mode 100644
>> index 0000000..d3166ec
>> --- /dev/null
>> +++ b/recipes/libfann/libfann_2.0.0.bb
>> @@ -0,0 +1,23 @@
>> +# libfann-2.0.0 recipie
>> +SECTION = "libs"
>> +DEFAULT_PREFERENCE = "1"
>> +
>> +# Package information
>> +DESCRIPTION = "libfann, Fast Artificial Neural Network Library is a
>> free open source neural network library, which implements multilayer
>> artificial neural networks in C with support for both fully connected
>> and sparsely connected networks."
>> +LICENSE = "BSD"
>> +PN = "libfann"
>> +PV = "2.0.0"
>> +PR = "r01"
>> +
>> +SRC_URI = "http://prdownloads.sourceforge.net/fann/fann-${PV}.tar.bz2"
>> +
>> +S = "${WORKDIR}/fann-${PV}"
>> +
>> +inherit autotools pkgconfig
>> +
>> +do_stage () {
>> + oe_libinstall -a -so -C src libfann ${STAGING_LIBDIR}
>> + install -d ${STAGING_INCDIR}/fann
>> + (cd ${S}/src/include; cp compat_time.h config.h doublefann.h fann.h
>> fann_activation.h fann_cascade.h fann_data.h fann_error.h
>> fann_internal.h fann_io.h fann_train.h fixedfann.h floatfann.h
>> ${STAGING_INCDIR}/fann/)
>> + install -m 0644 ${S}/aclocal.m4 ${STAGING_DATADIR}/aclocal/
>> +}
> 
> Can't you use autotools_stage to stage all this? And if not, don't use 
> 'cp', but 'install'.

 From the emails, it seems like the code that uses the headers expects 
them to be in the subdir. It would be worth looking at where they get 
installed on something like Debian or Fedora to be consistent.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Patch for libfann-2.0.0 recipe

[Elvis Dowson]

Hi,
	If we use

inherit autotools_stage pkgconfig

it will install the header files into ${STAGING_INCDIR}. So just to  
keep it neat and organized, Justin and myself thought it best that we  
put it in a subfolder  ${STAGING_INCDIR}/fann, just to keep things  
organized.

You can call it from the code as #include <fann.h> if  you use  
autotools_stage, or if you create the do_stage() method, an ensure  
that the fann library headers get put in the ${STAGING_INCDIR}/fann,  
called it from the code as #include <fann/fann.h>

Elvis

Re: Patch for libfann-2.0.0 recipe

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

Elvis Dowson wrote:
> Hi,
>     If we use
> 
> inherit autotools_stage pkgconfig
> 
> it will install the header files into ${STAGING_INCDIR}. So just to keep 
> it neat and organized, Justin and myself thought it best that we put it 
> in a subfolder  ${STAGING_INCDIR}/fann, just to keep things organized.
> 
> You can call it from the code as #include <fann.h> if  you use 
> autotools_stage, or if you create the do_stage() method, an ensure that 
> the fann library headers get put in the ${STAGING_INCDIR}/fann, called 
> it from the code as #include <fann/fann.h>

My copy of Fedora 8 also installs the headers into include/fann. 
Basically, if you know of anything using libfann on the desktop distros, 
I'd copy what they did.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Patch for libfann-2.0.0 recipe

[Koen Kooi]

On 16-06-09 21:00, Elvis Dowson wrote:
> Hi,
> If we use
>
> inherit autotools_stage pkgconfig
>
> it will install the header files into ${STAGING_INCDIR}.

And that's the way to go. Custom staging functions should die.

regards,

Koen

Re: Patch for libfann-2.0.0 recipe

[Rolf Leggewie]

Elvis Dowson wrote:
> Hi,
> 	I'm attaching a patch for the libfann-2.0.0 recipe for inclusion into  
> the oe repository.

Elvis,

thank you for the recipe.  Can you please take a look at 
http://wiki.openembedded.net/index.php/Styleguide and reorder the fields 
accordingly?  I think there is also a script in the contrib directory to 
help with this.

Regards

Rolf

Re: Patch for libfann-2.0.0 recipe

[Elvis Dowson]

Hi Rolf,

On Jun 17, 2009, at 8:43 AM, Rolf Leggewie wrote:

> Can you please take a look at http://wiki.openembedded.net/index.php/Styleguide 
>  and reorder the fields accordingly?  I think there is also a script  
> in the contrib directory to help with this.

Here is the modified recipe: recipes/libfann/libfann-2.0.0.bb

DESCRIPTION = "Fast Artificial Neural Network Library"
HOMEPAGE = "http://leenissen.dk/fann/"
SECTION = "libs"
LICENSE = "BSD"
SRCDATE = "20090618"
PV = "2.0.0"
PR = "r01"

SRC_URI = "http://prdownloads.sourceforge.net/fann/fann-${PV}.tar.bz2"

S = "${WORKDIR}/fann-${PV}"

inherit autotools pkgconfig

do_stage () {
	oe_libinstall -a -so -C src libfann ${STAGING_LIBDIR}
	install -d ${STAGING_INCDIR}/fann
	(cd ${S}/src/include; cp compat_time.h config.h doublefann.h fann.h  
fann_activation.h fann_cascade.h fann_data.h fann_error.h  
fann_internal.h fann_io.h fann_train.h fixedfann.h floatfann.h $ 
{STAGING_INCDIR}/fann/)
	install -m 0644 ${S}/aclocal.m4 ${STAGING_DATADIR}/aclocal/
}


Best regards,

Elvis

Re: Patch for libfann-2.0.0 recipe

[Koen Kooi]

On 18-06-09 18:05, Elvis Dowson wrote:
> Hi Rolf,
>
> On Jun 17, 2009, at 8:43 AM, Rolf Leggewie wrote:
>
>> Can you please take a look at
>> http://wiki.openembedded.net/index.php/Styleguide and reorder the
>> fields accordingly? I think there is also a script in the contrib
>> directory to help with this.
>
> Here is the modified recipe: recipes/libfann/libfann-2.0.0.bb
>
> DESCRIPTION = "Fast Artificial Neural Network Library"
> HOMEPAGE = "http://leenissen.dk/fann/"
> SECTION = "libs"
> LICENSE = "BSD"
> SRCDATE = "20090618"
> PV = "2.0.0"

> PR = "r01"

Don't set PR to that.

> SRC_URI = "http://prdownloads.sourceforge.net/fann/fann-${PV}.tar.bz2"
>
> S = "${WORKDIR}/fann-${PV}"
>
> inherit autotools pkgconfig

use AUTOTOOLS_STAGE_PKGCONFIG = "1"

> do_stage () {
> oe_libinstall -a -so -C src libfann ${STAGING_LIBDIR}
> install -d ${STAGING_INCDIR}/fann
> (cd ${S}/src/include; cp compat_time.h config.h doublefann.h fann.h
> fann_activation.h fann_cascade.h fann_data.h fann_error.h
> fann_internal.h fann_io.h fann_train.h fixedfann.h floatfann.h
> ${STAGING_INCDIR}/fann/)
> install -m 0644 ${S}/aclocal.m4 ${STAGING_DATADIR}/aclocal/
> }

Again, don't use custom staging methods for silly reasons.

Re: Patch for libfann-2.0.0 recipe

[Otavio Salvador]

Hello Koen,

On Thu, Jun 18, 2009 at 1:48 PM, Koen Kooi<k.kooi@student.utwente.nl> wrote:
>> PR = "r01"
>
> Don't set PR to that.

I believe that most people prefer to always have PR field included;
obviously it ought to be PR = "r1" or PR = "r0" but it is harder to
forget to update it when it shows in the recipe.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: Patch for libfann-2.0.0 recipe

[Koen Kooi]

On 18-06-09 18:52, Otavio Salvador wrote:
> Hello Koen,
>
> On Thu, Jun 18, 2009 at 1:48 PM, Koen Kooi<k.kooi@student.utwente.nl>  wrote:
>>> PR = "r01"
>>
>> Don't set PR to that.
>
> I believe that most people prefer to always have PR field included;
> obviously it ought to be PR = "r1" or PR = "r0" but it is harder to
> forget to update it when it shows in the recipe.

That's nonsense. Not setting PR = "r0" in recipes makes maintenance a 
lot easier, e.g. forcing rebuild or all xorg libs. If every recipe was 
already using INC_PR, I might agree with you, but since that isn't the 
case adding PR = "r0" is creating more work.

regards,

Koen

Re: Patch for libfann-2.0.0 recipe

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

Koen Kooi wrote:
> On 18-06-09 18:05, Elvis Dowson wrote:
>> Hi Rolf,
>>
>> On Jun 17, 2009, at 8:43 AM, Rolf Leggewie wrote:
>>
>>> Can you please take a look at
>>> http://wiki.openembedded.net/index.php/Styleguide and reorder the
>>> fields accordingly? I think there is also a script in the contrib
>>> directory to help with this.
>>
>> Here is the modified recipe: recipes/libfann/libfann-2.0.0.bb
>>
>> DESCRIPTION = "Fast Artificial Neural Network Library"
>> HOMEPAGE = "http://leenissen.dk/fann/"
>> SECTION = "libs"
>> LICENSE = "BSD"
>> SRCDATE = "20090618"
>> PV = "2.0.0"
> 
>> PR = "r01"
> 
> Don't set PR to that.
> 
>> SRC_URI = "http://prdownloads.sourceforge.net/fann/fann-${PV}.tar.bz2"
>>
>> S = "${WORKDIR}/fann-${PV}"
>>
>> inherit autotools pkgconfig
> 
> use AUTOTOOLS_STAGE_PKGCONFIG = "1"
> 
>> do_stage () {
>> oe_libinstall -a -so -C src libfann ${STAGING_LIBDIR}
>> install -d ${STAGING_INCDIR}/fann
>> (cd ${S}/src/include; cp compat_time.h config.h doublefann.h fann.h
>> fann_activation.h fann_cascade.h fann_data.h fann_error.h
>> fann_internal.h fann_io.h fann_train.h fixedfann.h floatfann.h
>> ${STAGING_INCDIR}/fann/)
>> install -m 0644 ${S}/aclocal.m4 ${STAGING_DATADIR}/aclocal/
>> }
> 
> Again, don't use custom staging methods for silly reasons.

I don't think the reason here is silly. I checked on my Fedora box and 
it installs the headers in include/fann/*.h also. The headers may need 
installing here so we can avoid patching existing software. I'm not 
intimately familiar with fann, so it would be great if people who are 
could look at this.

If there is not an existing set of sw using fann, then creating a custom 
staging method should be avoided.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Patch for libfann-2.0.0 recipe

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

Koen Kooi wrote:
> On 18-06-09 18:52, Otavio Salvador wrote:
>> Hello Koen,
>>
>> On Thu, Jun 18, 2009 at 1:48 PM, Koen Kooi<k.kooi@student.utwente.nl>  
>> wrote:
>>>> PR = "r01"
>>>
>>> Don't set PR to that.
>>
>> I believe that most people prefer to always have PR field included;
>> obviously it ought to be PR = "r1" or PR = "r0" but it is harder to
>> forget to update it when it shows in the recipe.
> 
> That's nonsense. Not setting PR = "r0" in recipes makes maintenance a 
> lot easier, e.g. forcing rebuild or all xorg libs. If every recipe was 
> already using INC_PR, I might agree with you, but since that isn't the 
> case adding PR = "r0" is creating more work.

Can you explain this a little clearer? I know a number of people on the 
list feel like Otavio and it would be really helpful for people to 
understand what the downside is to starting with PR = "r0" instead of 
leaving it out.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Patch for libfann-2.0.0 recipe

[Koen Kooi]

On 18-06-09 20:09, Philip Balister wrote:
> Koen Kooi wrote:
>> On 18-06-09 18:05, Elvis Dowson wrote:
>>> Hi Rolf,
>>>
>>> On Jun 17, 2009, at 8:43 AM, Rolf Leggewie wrote:
>>>
>>>> Can you please take a look at
>>>> http://wiki.openembedded.net/index.php/Styleguide and reorder the
>>>> fields accordingly? I think there is also a script in the contrib
>>>> directory to help with this.
>>>
>>> Here is the modified recipe: recipes/libfann/libfann-2.0.0.bb
>>>
>>> DESCRIPTION = "Fast Artificial Neural Network Library"
>>> HOMEPAGE = "http://leenissen.dk/fann/"
>>> SECTION = "libs"
>>> LICENSE = "BSD"
>>> SRCDATE = "20090618"
>>> PV = "2.0.0"
>>
>>> PR = "r01"
>>
>> Don't set PR to that.
>>
>>> SRC_URI = "http://prdownloads.sourceforge.net/fann/fann-${PV}.tar.bz2"
>>>
>>> S = "${WORKDIR}/fann-${PV}"
>>>
>>> inherit autotools pkgconfig
>>
>> use AUTOTOOLS_STAGE_PKGCONFIG = "1"
>>
>>> do_stage () {
>>> oe_libinstall -a -so -C src libfann ${STAGING_LIBDIR}
>>> install -d ${STAGING_INCDIR}/fann
>>> (cd ${S}/src/include; cp compat_time.h config.h doublefann.h fann.h
>>> fann_activation.h fann_cascade.h fann_data.h fann_error.h
>>> fann_internal.h fann_io.h fann_train.h fixedfann.h floatfann.h
>>> ${STAGING_INCDIR}/fann/)
>>> install -m 0644 ${S}/aclocal.m4 ${STAGING_DATADIR}/aclocal/
>>> }
>>
>> Again, don't use custom staging methods for silly reasons.
>
> I don't think the reason here is silly. I checked on my Fedora box and
> it installs the headers in include/fann/*.h also. The headers may need
> installing here so we can avoid patching existing software. I'm not
> intimately familiar with fann, so it would be great if people who are
> could look at this.

I think the fann authors know best where to install their to, which 
means using autotools_stage_all.

regards,

Koen

Re: Patch for libfann-2.0.0 recipe

[Koen Kooi]

On 18-06-09 20:11, Philip Balister wrote:
> Koen Kooi wrote:
>> On 18-06-09 18:52, Otavio Salvador wrote:
>>> Hello Koen,
>>>
>>> On Thu, Jun 18, 2009 at 1:48 PM, Koen Kooi<k.kooi@student.utwente.nl>
>>> wrote:
>>>>> PR = "r01"
>>>>
>>>> Don't set PR to that.
>>>
>>> I believe that most people prefer to always have PR field included;
>>> obviously it ought to be PR = "r1" or PR = "r0" but it is harder to
>>> forget to update it when it shows in the recipe.
>>
>> That's nonsense. Not setting PR = "r0" in recipes makes maintenance a
>> lot easier, e.g. forcing rebuild or all xorg libs. If every recipe was
>> already using INC_PR, I might agree with you, but since that isn't the
>> case adding PR = "r0" is creating more work.
>
> Can you explain this a little clearer? I know a number of people on the
> list feel like Otavio and it would be really helpful for people to
> understand what the downside is to starting with PR = "r0" instead of
> leaving it out.

Suppose you want to bump PR on every xorg lib recipe, do you want to 
edit 70 recipes or do you only want to edit 1 .inc file and 3 recipes? 
If you're in the 'edit 70 recipes' crowd, add PR = "r0" to all recipes 
in OE. If not, leave it out, bitbake defaults to it anyway.
Also, does anyone remember how much pain we had when adding ${PN}-dbg 
into the default PACKAGES only to discover that lots of recipes were 
needlessly copying defaults?

regards,

Koen

Re: Patch for libfann-2.0.0 recipe

[Elvis Dowson]

Hi Koen,

On Jun 18, 2009, at 10:14 PM, Koen Kooi wrote:
>
> I think the fann authors know best where to install their to, which  
> means using autotools_stage_all.
>

Not really, atleast I'm new to oe, and it took me a while to get to  
this stage. I can find my way around a bit now, but I really can't  
understand the pros and cons of using PR, INC_PR, etc. Most of the  
recipes in oe all use PR anyway.

I just pitched in to help Justin out. And thought I'd just submit the  
patch back. You may alter it and incorporate it as you see fit.

Elvis

Re: Patch for libfann-2.0.0 recipe

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

Elvis Dowson wrote:
> Hi Koen,
> 
> On Jun 18, 2009, at 10:14 PM, Koen Kooi wrote:
>>
>> I think the fann authors know best where to install their to, which 
>> means using autotools_stage_all.
>>
> 
> Not really, atleast I'm new to oe, and it took me a while to get to this 
> stage. I can find my way around a bit now, but I really can't understand 
> the pros and cons of using PR, INC_PR, etc. Most of the recipes in oe 
> all use PR anyway.
> 
> I just pitched in to help Justin out. And thought I'd just submit the 
> patch back. You may alter it and incorporate it as you see fit.

I think we've flogged this horse to death.

Koen has convinced me Fedora is staging the headers to the wrong place 
by pointing out:

http://packages.debian.org/search?searchon=contents&keywords=fann.h&mode=exactfilename&suite=unstable&arch=any

using the argument "OE follows debian, not Redhat".

I'll look over the bb file and commit it based on the comments. Thanks 
for your patience Elvis.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Patch for libfann-2.0.0 recipe

[Tom Rini]

On Thu, Jun 18, 2009 at 08:24:29PM +0200, Koen Kooi wrote:
> On 18-06-09 20:11, Philip Balister wrote:
>> Koen Kooi wrote:
>>> On 18-06-09 18:52, Otavio Salvador wrote:
>>>> Hello Koen,
>>>>
>>>> On Thu, Jun 18, 2009 at 1:48 PM, Koen Kooi<k.kooi@student.utwente.nl>
>>>> wrote:
>>>>>> PR = "r01"
>>>>>
>>>>> Don't set PR to that.
>>>>
>>>> I believe that most people prefer to always have PR field included;
>>>> obviously it ought to be PR = "r1" or PR = "r0" but it is harder to
>>>> forget to update it when it shows in the recipe.
>>>
>>> That's nonsense. Not setting PR = "r0" in recipes makes maintenance a
>>> lot easier, e.g. forcing rebuild or all xorg libs. If every recipe was
>>> already using INC_PR, I might agree with you, but since that isn't the
>>> case adding PR = "r0" is creating more work.
>>
>> Can you explain this a little clearer? I know a number of people on the
>> list feel like Otavio and it would be really helpful for people to
>> understand what the downside is to starting with PR = "r0" instead of
>> leaving it out.
>
> Suppose you want to bump PR on every xorg lib recipe, do you want to  
> edit 70 recipes or do you only want to edit 1 .inc file and 3 recipes?  
> If you're in the 'edit 70 recipes' crowd, add PR = "r0" to all recipes  
> in OE. If not, leave it out, bitbake defaults to it anyway.
> Also, does anyone remember how much pain we had when adding ${PN}-dbg  
> into the default PACKAGES only to discover that lots of recipes were  
> needlessly copying defaults?

But there's no .inc file here.  How about saying:
- Adding an .inc file MUST switch all the recipes now using it to INC_PR
- If you're modifying recipes that really should be INC_PR, make them
  INC_PR while you're in there (the 70 xorg lib recipes not using INC_PR
  today for example).
- New recipes that also create a .inc must set INC_PR = "r0" / PR =
  "${INC_PR}.0"
- New recipes that are just a single .bb must set PR = "r0"

The arguement against "leave it out, bitbake defaults to it anyway." is
that "once you make a change it's easier to forget to bump PR/INC_PR if
it's not staring you in the face".

-- 
Tom Rini

Re: Patch for libfann-2.0.0 recipe

[Otavio Salvador]

Full support for your proposal Tom :-)

On Thu, Jun 18, 2009 at 8:05 PM, Tom Rini<trini@embeddedalley.com> wrote:
> On Thu, Jun 18, 2009 at 08:24:29PM +0200, Koen Kooi wrote:
>> On 18-06-09 20:11, Philip Balister wrote:
>>> Koen Kooi wrote:
>>>> On 18-06-09 18:52, Otavio Salvador wrote:
>>>>> Hello Koen,
>>>>>
>>>>> On Thu, Jun 18, 2009 at 1:48 PM, Koen Kooi<k.kooi@student.utwente.nl>
>>>>> wrote:
>>>>>>> PR = "r01"
>>>>>>
>>>>>> Don't set PR to that.
>>>>>
>>>>> I believe that most people prefer to always have PR field included;
>>>>> obviously it ought to be PR = "r1" or PR = "r0" but it is harder to
>>>>> forget to update it when it shows in the recipe.
>>>>
>>>> That's nonsense. Not setting PR = "r0" in recipes makes maintenance a
>>>> lot easier, e.g. forcing rebuild or all xorg libs. If every recipe was
>>>> already using INC_PR, I might agree with you, but since that isn't the
>>>> case adding PR = "r0" is creating more work.
>>>
>>> Can you explain this a little clearer? I know a number of people on the
>>> list feel like Otavio and it would be really helpful for people to
>>> understand what the downside is to starting with PR = "r0" instead of
>>> leaving it out.
>>
>> Suppose you want to bump PR on every xorg lib recipe, do you want to
>> edit 70 recipes or do you only want to edit 1 .inc file and 3 recipes?
>> If you're in the 'edit 70 recipes' crowd, add PR = "r0" to all recipes
>> in OE. If not, leave it out, bitbake defaults to it anyway.
>> Also, does anyone remember how much pain we had when adding ${PN}-dbg
>> into the default PACKAGES only to discover that lots of recipes were
>> needlessly copying defaults?
>
> But there's no .inc file here.  How about saying:
> - Adding an .inc file MUST switch all the recipes now using it to INC_PR
> - If you're modifying recipes that really should be INC_PR, make them
>  INC_PR while you're in there (the 70 xorg lib recipes not using INC_PR
>  today for example).
> - New recipes that also create a .inc must set INC_PR = "r0" / PR =
>  "${INC_PR}.0"
> - New recipes that are just a single .bb must set PR = "r0"
>
> The arguement against "leave it out, bitbake defaults to it anyway." is
> that "once you make a change it's easier to forget to bump PR/INC_PR if
> it's not staring you in the face".
>
> --
> Tom Rini
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: Patch for libfann-2.0.0 recipe

[Koen Kooi]

On 19-06-09 01:05, Tom Rini wrote:
> On Thu, Jun 18, 2009 at 08:24:29PM +0200, Koen Kooi wrote:
>> On 18-06-09 20:11, Philip Balister wrote:
>>> Koen Kooi wrote:
>>>> On 18-06-09 18:52, Otavio Salvador wrote:
>>>>> Hello Koen,
>>>>>
>>>>> On Thu, Jun 18, 2009 at 1:48 PM, Koen Kooi<k.kooi@student.utwente.nl>
>>>>> wrote:
>>>>>>> PR = "r01"
>>>>>>
>>>>>> Don't set PR to that.
>>>>>
>>>>> I believe that most people prefer to always have PR field included;
>>>>> obviously it ought to be PR = "r1" or PR = "r0" but it is harder to
>>>>> forget to update it when it shows in the recipe.
>>>>
>>>> That's nonsense. Not setting PR = "r0" in recipes makes maintenance a
>>>> lot easier, e.g. forcing rebuild or all xorg libs. If every recipe was
>>>> already using INC_PR, I might agree with you, but since that isn't the
>>>> case adding PR = "r0" is creating more work.
>>>
>>> Can you explain this a little clearer? I know a number of people on the
>>> list feel like Otavio and it would be really helpful for people to
>>> understand what the downside is to starting with PR = "r0" instead of
>>> leaving it out.
>>
>> Suppose you want to bump PR on every xorg lib recipe, do you want to
>> edit 70 recipes or do you only want to edit 1 .inc file and 3 recipes?
>> If you're in the 'edit 70 recipes' crowd, add PR = "r0" to all recipes
>> in OE. If not, leave it out, bitbake defaults to it anyway.
>> Also, does anyone remember how much pain we had when adding ${PN}-dbg
>> into the default PACKAGES only to discover that lots of recipes were
>> needlessly copying defaults?
>
> But there's no .inc file here.  How about saying:
> - Adding an .inc file MUST switch all the recipes now using it to INC_PR
> - If you're modifying recipes that really should be INC_PR, make them
>    INC_PR while you're in there (the 70 xorg lib recipes not using INC_PR
>    today for example).
> - New recipes that also create a .inc must set INC_PR = "r0" / PR =
>    "${INC_PR}.0"
> - New recipes that are just a single .bb must set PR = "r0"
>
> The arguement against "leave it out, bitbake defaults to it anyway." is
> that "once you make a change it's easier to forget to bump PR/INC_PR if
> it's not staring you in the face".

Shall we start putting every var in a recipe then? Setting vars to their 
default is just bloat and wastes parse time.

Re: Patch for libfann-2.0.0 recipe

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

Elvis Dowson wrote:
> Hi Koen,
> 
> On Jun 18, 2009, at 10:14 PM, Koen Kooi wrote:
>>
>> I think the fann authors know best where to install their to, which 
>> means using autotools_stage_all.
>>
> 
> Not really, atleast I'm new to oe, and it took me a while to get to this 
> stage. I can find my way around a bit now, but I really can't understand 
> the pros and cons of using PR, INC_PR, etc. Most of the recipes in oe 
> all use PR anyway.
> 
> I just pitched in to help Justin out. And thought I'd just submit the 
> patch back. You may alter it and incorporate it as you see fit.

I committed a recipe in:

http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=617f8b6d64b7d3f47eb8c8ddd56817e9577f354f

I staged the headers into /usr/include (following Debian, not 
Redhat/Fedora). If you have recipes that use fann and are having trouble 
with this, ask once on the list, and we will try and suggest fixes for 
the recipes for the cases that expect the headers in <fann/fann.h>.

Thanks,

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Patch for libfann-2.0.0 recipe

[Elvis Dowson]

Cool, thanks Philip! :-)

Elvis

On Jun 19, 2009, at 5:37 PM, Philip Balister wrote:

> Elvis Dowson wrote:
>> Hi Koen,
>> On Jun 18, 2009, at 10:14 PM, Koen Kooi wrote:
>>>
>>> I think the fann authors know best where to install their to,  
>>> which means using autotools_stage_all.
>>>
>> Not really, atleast I'm new to oe, and it took me a while to get to  
>> this stage. I can find my way around a bit now, but I really can't  
>> understand the pros and cons of using PR, INC_PR, etc. Most of the  
>> recipes in oe all use PR anyway.
>> I just pitched in to help Justin out. And thought I'd just submit  
>> the patch back. You may alter it and incorporate it as you see fit.
>
> I committed a recipe in:
>
> http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=617f8b6d64b7d3f47eb8c8ddd56817e9577f354f
>
> I staged the headers into /usr/include (following Debian, not Redhat/ 
> Fedora). If you have recipes that use fann and are having trouble  
> with this, ask once on the list, and we will try and suggest fixes  
> for the recipes for the cases that expect the headers in <fann/ 
> fann.h>.
>
> Thanks,
>
> Philip
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Patch for libfann-2.0.0 recipe

[Tom Rini]

On Fri, Jun 19, 2009 at 10:06:18AM +0200, Koen Kooi wrote:
> On 19-06-09 01:05, Tom Rini wrote:
>> On Thu, Jun 18, 2009 at 08:24:29PM +0200, Koen Kooi wrote:
>>> On 18-06-09 20:11, Philip Balister wrote:
>>>> Koen Kooi wrote:
>>>>> On 18-06-09 18:52, Otavio Salvador wrote:
>>>>>> Hello Koen,
>>>>>>
>>>>>> On Thu, Jun 18, 2009 at 1:48 PM, Koen Kooi<k.kooi@student.utwente.nl>
>>>>>> wrote:
>>>>>>>> PR = "r01"
>>>>>>>
>>>>>>> Don't set PR to that.
>>>>>>
>>>>>> I believe that most people prefer to always have PR field included;
>>>>>> obviously it ought to be PR = "r1" or PR = "r0" but it is harder to
>>>>>> forget to update it when it shows in the recipe.
>>>>>
>>>>> That's nonsense. Not setting PR = "r0" in recipes makes maintenance a
>>>>> lot easier, e.g. forcing rebuild or all xorg libs. If every recipe was
>>>>> already using INC_PR, I might agree with you, but since that isn't the
>>>>> case adding PR = "r0" is creating more work.
>>>>
>>>> Can you explain this a little clearer? I know a number of people on the
>>>> list feel like Otavio and it would be really helpful for people to
>>>> understand what the downside is to starting with PR = "r0" instead of
>>>> leaving it out.
>>>
>>> Suppose you want to bump PR on every xorg lib recipe, do you want to
>>> edit 70 recipes or do you only want to edit 1 .inc file and 3 recipes?
>>> If you're in the 'edit 70 recipes' crowd, add PR = "r0" to all recipes
>>> in OE. If not, leave it out, bitbake defaults to it anyway.
>>> Also, does anyone remember how much pain we had when adding ${PN}-dbg
>>> into the default PACKAGES only to discover that lots of recipes were
>>> needlessly copying defaults?
>>
>> But there's no .inc file here.  How about saying:
>> - Adding an .inc file MUST switch all the recipes now using it to INC_PR
>> - If you're modifying recipes that really should be INC_PR, make them
>>    INC_PR while you're in there (the 70 xorg lib recipes not using INC_PR
>>    today for example).
>> - New recipes that also create a .inc must set INC_PR = "r0" / PR =
>>    "${INC_PR}.0"
>> - New recipes that are just a single .bb must set PR = "r0"
>>
>> The arguement against "leave it out, bitbake defaults to it anyway." is
>> that "once you make a change it's easier to forget to bump PR/INC_PR if
>> it's not staring you in the face".
>
> Shall we start putting every var in a recipe then? Setting vars to their  
> default is just bloat and wastes parse time.

If there's other variables that need to be changed, frequently, from
their default value after the first commit, yes, we should put those in
as well.

I would have assumed that since changing a package without changing the
PR can wreck havoc on public feeds you would be in favor of helping to
keep those problems at bay.

-- 
Tom Rini

Re: Patch for libfann-2.0.0 recipe

[Koen Kooi]

On 19-06-09 19:47, Tom Rini wrote:

> I would have assumed that since changing a package without changing the
> PR can wreck havoc on public feeds you would be in favor of helping to
> keep those problems at bay.

Check contrib/angstrom/upload-packages.sh :) It won't upload any 
duplicate filenames, so angstrom public feeds don't suffer from such 
things (they did, that's why Graeme and I added that logic).
Anyway, if you aren't paying enough attention to bump PR, you shouldn't 
be pushing that commit!
There are a lot more things that warrant attention than not including PR 
= "r0" in the recipe, inheriting pkgconfig being one of them.

regards,

Koen