dmidecode: fix fetch path to use BP
PATCH 1/1 dmidecode: fix fetch path to use BP
This is so the multilib prefix is not used
--- meta/recipes-devtools/dmidecode/dmidecode_2.12.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-devtools/dmidecode/dmidecode_2.12.bb +1 -1
@@ -4,7 +4,7 @@ LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://LICENSE;md5=393a5ca445f6965873eca0259a17f833" PR = "r0" -SRC_URI = "http://savannah.nongnu.org/download/dmidecode/${P}.tar.bz2" +SRC_URI = "http://savannah.nongnu.org/download/dmidecode/${BP}.tar.bz2" COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
Signature · 1 line
1.8.0.2
Quoted 1 line · Saul Wold
This is so the multilib prefix is not used
Thanks for catching that Saul. How do we know when to use P and when to use BP? Where should this be documented? Maybe in the dev manual for writing new recipes?
--
Darren
Quoted 19 lines
Signed-off-by Saul Wold <[email protected]>--- meta/recipes-devtools/dmidecode/dmidecode_2.12.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)meta/recipes-devtools/dmidecode/dmidecode_2.12.bb +1
-1@@ -4,7 +4,7 @@ LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://LICENSE;md5=393a5ca445f6965873eca0259a17f833" PR = "r0" -SRC_URI = "http://savannah.nongnu.org/download/dmidecode/${P}.tar.bz2" +SRC_URI = "http://savannah.nongnu.org/download/dmidecode/${BP}.tar.bz2" COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel
Quoted 5 lines · On Friday 03 May 2013 19:41:03 Darren Hart wrote:
Quoted 1 line · Saul Wold
This is so the multilib prefix is not used
Thanks for catching that Saul. How do we know when to use P and when to use BP?
The easiest thing is to imagine what would happen were the recipe to be BBCLASSEXTENDed to native - would xyz-native make sense where you've used the reference, or does it always need to be xyz regardless of how it is being built? If the former, PN (or P with the version); if the latter, BPN (or BP with the version).
Quoted 2 lines
Where should this be documented? Maybe in the dev manual for writing new recipes?
It was pointed out recently on IRC that we may need to expand and adjust the section in the dev manual so it provides more of a step-by-step guide to creating a recipe, and I plan to work with Scott to do that for this cycle, so we should be able to include this as part of that.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 5 lines · Paul Eggleton
The easiest thing is to imagine what would happen were the recipe to be BBCLASSEXTENDed to native - would xyz-native make sense where you've used the reference, or does it always need to be xyz regardless of how it is being built? If the former, PN (or P with the version); if the latter, BPN (or BP with the version).
I've been hitting errors related to this when doing ML builds which is a good one for breakage as PN gets prefixed, and fixing where they were causing errors. I was thinking it would make sense for some common-sense sanity checks to be done - ie SRC_URI shouldn't contain PN, FILES_foo shouldn't contain BPN (the foo bit, that is), and so on.
Ross
Quoted 16 lines · Paul Eggleton
Quoted 5 lines · On Friday 03 May 2013 19:41:03 Darren Hart wrote:
Quoted 1 line · Saul Wold
This is so the multilib prefix is not used
Thanks for catching that Saul. How do we know when to use P and when to use BP?
The easiest thing is to imagine what would happen were the recipe to be BBCLASSEXTENDed to native - would xyz-native make sense where you've used the reference, or does it always need to be xyz regardless of how it is being built? If the former, PN (or P with the version); if the latter, BPN (or BP with the version).
Quoted 2 lines
Where should this be documented? Maybe in the dev manual for writing new recipes?
Quoted 7 lines
It was pointed out recently on IRC that we may need to expand and adjust the section in the dev manual so it provides more of a step-by-step guide to creating a recipe, and I plan to work with Scott to do that for this cycle, so we should be able to include this as part of that.
Cheers,
Paul
Thank you Paul!
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel