| Submitter | Bernhard Reutner-Fischer |
|---|---|
| Date | 2010-02-13 12:51:46 |
| Message ID | <20100213125146.GJ10632@mx.loc> |
| Download | mbox | patch |
| Permalink | /patch/1587/ |
| State | Applied, archived |
| Headers | show |
Comments
On Sat, 2010-02-13 at 13:51 +0100, Bernhard Reutner-Fischer wrote: > It would indeed. Can i somehow say > file1: SRC="http:://one.ext/one.tar.xz" > SRC[md5sum]=md5 > SRC[sha256sum]=sha256 > or, perhaps it's the basename if there was no ;name= > SRC[one.tar.xz.md5sum]=md5 > SRC[one.tar.xz.sha256sum]=sha256 > file2: SRC="git://two" > inc: FOO_SRC ?= SRC > SRC_URI += FOO_SRC I don't think this needs to be as complicated as you are making it. You should be able to simply move your original SRC_URI verbatim to the .inc file, i.e.: SRC_URI = "http://tukaani.org/xz/xz-${PV}.tar.bz2;name=xz" and then, in the individual .bb files for each version, write: SRC_URI[xz.md5sum] = ... There's no requirement for the two things to be in the same file. If you need to add other things like patches to the SRC_URI for a specific version, you can just write: SRC_URI += "file://..." in the .bb file in question. > Revised patch is attached, but: > it works for the 4.999beta9 version (literally, since that's how > upstream calls the tarball; Is this a problem with the version-naming > like Koon indicates?) It rather depends on what upstream are going to do next. If "4.999" is the number that they are using for pre-releases leading up to 5.0, and everything in the 4.999 series is going to be a beta (i.e. they do 4.999.8beta, 4.999.9beta, 4.999.10beta, 5.0) then it is probably fine as it stands. But, if there is any risk that "4.999.9beta" might be followed at some point by a version called just "4.999.9", or even "4.999", then that would be a problem because the latter version will sort lower than the former. > since: $ ls -a ../sources/git/ctrl.tukaani.org.xz.git/ > . .. 1 .git > > "1" ?! That is rather weird. I can't see any obvious cause for that from a quick inspection of the files you attached. p.
On Sat, Feb 13, 2010 at 01:19:29PM +0000, Phil Blundell wrote: >On Sat, 2010-02-13 at 13:51 +0100, Bernhard Reutner-Fischer wrote: >> It would indeed. Can i somehow say >> file1: SRC="http:://one.ext/one.tar.xz" >> SRC[md5sum]=md5 >> SRC[sha256sum]=sha256 >> or, perhaps it's the basename if there was no ;name= >> SRC[one.tar.xz.md5sum]=md5 >> SRC[one.tar.xz.sha256sum]=sha256 >> file2: SRC="git://two" >> inc: FOO_SRC ?= SRC >> SRC_URI += FOO_SRC > >I don't think this needs to be as complicated as you are making it. You >should be able to simply move your original SRC_URI verbatim to the .inc >file, i.e.: > >SRC_URI = "http://tukaani.org/xz/xz-${PV}.tar.bz2;name=xz" > >and then, in the individual .bb files for each version, write: > >SRC_URI[xz.md5sum] = ... > >There's no requirement for the two things to be in the same file. If >you need to add other things like patches to the SRC_URI for a specific >version, you can just write: > >SRC_URI += "file://..." > >in the .bb file in question. But that would clash with _git, wouldn't it, unless, and only if this exact sequence would be used: .inc:=S ?= ${WORKDIR}/xz-${PV} .inc:=SRC_URI=http 0815.bb:PV=0814+0815foo 0815.bb:require .inc 0815.bb:SRC_URI+=patch1 git.bb:S=${WORKDIR}/git git.bb:require .inc git.bb:SRC_URI=git which we can obey to in this case, but it somehow feels brittle altough it should work out fine in practise, i think. > >> Revised patch is attached, but: >> it works for the 4.999beta9 version (literally, since that's how >> upstream calls the tarball; Is this a problem with the version-naming >> like Koon indicates?) > >It rather depends on what upstream are going to do next. If "4.999" is >the number that they are using for pre-releases leading up to 5.0, and >everything in the 4.999 series is going to be a beta (i.e. they do >4.999.8beta, 4.999.9beta, 4.999.10beta, 5.0) then it is probably fine as >it stands. But, if there is any risk that "4.999.9beta" might be >followed at some point by a version called just "4.999.9", or even >"4.999", then that would be a problem because the latter version will >sort lower than the former. ACK, exactly. I follow Koon on this. > >> since: $ ls -a ../sources/git/ctrl.tukaani.org.xz.git/ >> . .. 1 .git >> >> "1" ?! > >That is rather weird. I can't see any obvious cause for that from a >quick inspection of the files you attached. Just try it out, that package shouldn't interfere with any existing recipe. To my untrained eyes it sounds like a glitch somewhere in infrastructure and not in those recipes, but YMV alot from mine in this respect :) Insights? TIA && cheers, Bernhard
On Sat, Feb 13, 2010 at 01:51:46PM +0100, Bernhard Reutner-Fischer wrote: >On Thu, Feb 11, 2010 at 12:53:01PM +0000, Phil Blundell wrote: >>On Wed, 2010-02-10 at 21:13 +0100, Bernhard Reutner-Fischer wrote: >>> index 0000000..bc5e9ff >>> --- /dev/null >>> +++ b/recipes/xz/xz-native.inc >>> @@ -0,0 +1,2 @@ >>> +inherit native >>> +require xz_${PV}.bb >> >>You could consider using BBCLASSEXTEND to eliminate the need for this >>separate recipe. > >Thanks for that, good thing. This will trim down alot on the number of >recipes in the tree! AFAICS BBCLASSEXTEND does not take canadian into account ATM, so i could convert mpfr without pain but gmp-canadian on darwin (at least 4.2.4 is mentioned in there) will/would break AFAICT, is that correct?
On Sat, 2010-02-13 at 15:37 +0100, Bernhard Reutner-Fischer wrote: > But that would clash with _git, wouldn't it, unless, and only if this > exact sequence would be used: > .inc:=S ?= ${WORKDIR}/xz-${PV} > .inc:=SRC_URI=http > 0815.bb:PV=0814+0815foo > 0815.bb:require .inc > 0815.bb:SRC_URI+=patch1 > git.bb:S=${WORKDIR}/git > git.bb:require .inc > git.bb:SRC_URI=git It would be more traditional to set S with a hard assignment in the .inc file, and simply override it (the same as SRC_URI) in the _git.bb file. But, essentially, yes, what you are describing there is basically what you'd have to do. There is plenty of precedent in OE for the general approach of using an .inc file to set generic defaults and then allowing particular .bb files to override the parts they don't want. I'll have a look at your git checkout issue later today. p.
On Sat, 2010-02-13 at 17:14 +0100, Bernhard Reutner-Fischer wrote: > On Sat, Feb 13, 2010 at 01:51:46PM +0100, Bernhard Reutner-Fischer wrote: > >On Thu, Feb 11, 2010 at 12:53:01PM +0000, Phil Blundell wrote: > >>On Wed, 2010-02-10 at 21:13 +0100, Bernhard Reutner-Fischer wrote: > >>> index 0000000..bc5e9ff > >>> --- /dev/null > >>> +++ b/recipes/xz/xz-native.inc > >>> @@ -0,0 +1,2 @@ > >>> +inherit native > >>> +require xz_${PV}.bb > >> > >>You could consider using BBCLASSEXTEND to eliminate the need for this > >>separate recipe. > > > >Thanks for that, good thing. This will trim down alot on the number of > >recipes in the tree! > > AFAICS BBCLASSEXTEND does not take canadian into account ATM, so i could > convert mpfr without pain but gmp-canadian on darwin (at least 4.2.4 is > mentioned in there) will/would break AFAICT, is that correct? Since I didn't see a reply... at current, yes BBLCASSEXTEND only covers -native (and not -cross, -cross-sdk/-sdk nor -canadian*).
Canadian seems to be deprecated in favour of nativesdk (which is handled by
BBCLASSEXTEND), so I will try use that instead.
On 25 Feb 2010 01:50, "Tom Rini" <tom_rini@mentor.com> wrote:
On Sat, 2010-02-13 at 17:14 +0100, Bernhard Reutner-Fischer wrote:
> On Sat, Feb 13, 2010 at 01:51:4...
Since I didn't see a reply... at current, yes BBLCASSEXTEND only covers
-native (and not -cross, -cross-sdk/-sdk nor -canadian*).
--
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation
On Wed, 2010-02-24 at 17:49 -0700, Tom Rini wrote: > On Sat, 2010-02-13 at 17:14 +0100, Bernhard Reutner-Fischer wrote: > > On Sat, Feb 13, 2010 at 01:51:46PM +0100, Bernhard Reutner-Fischer wrote: > > >On Thu, Feb 11, 2010 at 12:53:01PM +0000, Phil Blundell wrote: > > >>On Wed, 2010-02-10 at 21:13 +0100, Bernhard Reutner-Fischer wrote: > > >>> index 0000000..bc5e9ff > > >>> --- /dev/null > > >>> +++ b/recipes/xz/xz-native.inc > > >>> @@ -0,0 +1,2 @@ > > >>> +inherit native > > >>> +require xz_${PV}.bb > > >> > > >>You could consider using BBCLASSEXTEND to eliminate the need for this > > >>separate recipe. > > > > > >Thanks for that, good thing. This will trim down alot on the number of > > >recipes in the tree! > > > > AFAICS BBCLASSEXTEND does not take canadian into account ATM, so i could > > convert mpfr without pain but gmp-canadian on darwin (at least 4.2.4 is > > mentioned in there) will/would break AFAICT, is that correct? > > Since I didn't see a reply... at current, yes BBLCASSEXTEND only covers > -native (and not -cross, -cross-sdk/-sdk nor -canadian*). BBCLASSEXTEND covers -native and -nativesdk The -cross, -crosssdk, -canadian-cross and other combinations usually have too many differences to be worth the effort although it would be possible to make them work. Cheers, Richard
On Thu, 2010-02-25 at 08:41 +0100, Bernhard Reutner-Fischer wrote: > Canadian seems to be deprecated in favour of nativesdk (which is handled by > BBCLASSEXTEND), so I will try use that instead. Yes, -nativesdk is intended to replace -sdk packages Cheers, Richard
On Thu, 2010-02-25 at 10:39 +0000, Richard Purdie wrote: > On Wed, 2010-02-24 at 17:49 -0700, Tom Rini wrote: > > On Sat, 2010-02-13 at 17:14 +0100, Bernhard Reutner-Fischer wrote: > > > On Sat, Feb 13, 2010 at 01:51:46PM +0100, Bernhard Reutner-Fischer wrote: > > > >On Thu, Feb 11, 2010 at 12:53:01PM +0000, Phil Blundell wrote: > > > >>On Wed, 2010-02-10 at 21:13 +0100, Bernhard Reutner-Fischer wrote: > > > >>> index 0000000..bc5e9ff > > > >>> --- /dev/null > > > >>> +++ b/recipes/xz/xz-native.inc > > > >>> @@ -0,0 +1,2 @@ > > > >>> +inherit native > > > >>> +require xz_${PV}.bb > > > >> > > > >>You could consider using BBCLASSEXTEND to eliminate the need for this > > > >>separate recipe. > > > > > > > >Thanks for that, good thing. This will trim down alot on the number of > > > >recipes in the tree! > > > > > > AFAICS BBCLASSEXTEND does not take canadian into account ATM, so i could > > > convert mpfr without pain but gmp-canadian on darwin (at least 4.2.4 is > > > mentioned in there) will/would break AFAICT, is that correct? > > > > Since I didn't see a reply... at current, yes BBLCASSEXTEND only covers > > -native (and not -cross, -cross-sdk/-sdk nor -canadian*). > > BBCLASSEXTEND covers -native and -nativesdk Is the -nativesdk part implicit in the anonfuncs in nativesdk.bbclass or just not merged yet? > The -cross, -crosssdk, -canadian-cross and other combinations usually > have too many differences to be worth the effort although it would be > possible to make them work. I'm not so sure about that, but we'll see. I should have some form of canadian stuff working again shortly.
can someone explain what BBCLASSEXTEND does... sorry for the rookie question.
On Thu, 2010-02-25 at 10:21 -0700, Tom Rini wrote: > > BBCLASSEXTEND covers -native and -nativesdk > > Is the -nativesdk part implicit in the anonfuncs in nativesdk.bbclass or > just not merged yet? It should be implicit in the anonfuncs. If that class differs to Poky, the Poky changes should be merged though. > > The -cross, -crosssdk, -canadian-cross and other combinations usually > > have too many differences to be worth the effort although it would be > > possible to make them work. > > I'm not so sure about that, but we'll see. I should have some form of > canadian stuff working again shortly. You're unsure it would be possible to make them work of that its not worth the effort? Cheers, Richard
On Thu, Feb 25, 2010 at 08:16:21PM +0000, Richard Purdie wrote: >On Thu, 2010-02-25 at 10:21 -0700, Tom Rini wrote: >> > BBCLASSEXTEND covers -native and -nativesdk >> >> Is the -nativesdk part implicit in the anonfuncs in nativesdk.bbclass or >> just not merged yet? > >It should be implicit in the anonfuncs. If that class differs to Poky, >the Poky changes should be merged though. > >> > The -cross, -crosssdk, -canadian-cross and other combinations usually >> > have too many differences to be worth the effort although it would be >> > possible to make them work. >> >> I'm not so sure about that, but we'll see. I should have some form of >> canadian stuff working again shortly. > >You're unsure it would be possible to make them work of that its not >worth the effort? Tom? Yesterday evening i was building a pristine master reference again and saw that mpfr et al are (still) pretty outdated. AFAIR i cannot mix BBCLASSEXTEND vs. old-fashioned recipes for one package (didn't try if that's still true) so i'm, again, running into the issue of what to do with older toolchains needing that canadian stuff. I'm not too jazzed about the idea to touch the old toolchains just because i want to have current gmp/mpc/mpfr/gcc (using CLASSEXTEND nativesdk). So, how to proceed? cheers,
Bernhard Reutner-Fischer wrote: > On Thu, Feb 25, 2010 at 08:16:21PM +0000, Richard Purdie wrote: >> On Thu, 2010-02-25 at 10:21 -0700, Tom Rini wrote: >>>> BBCLASSEXTEND covers -native and -nativesdk >>> Is the -nativesdk part implicit in the anonfuncs in nativesdk.bbclass or >>> just not merged yet? >> It should be implicit in the anonfuncs. If that class differs to Poky, >> the Poky changes should be merged though. >> >>>> The -cross, -crosssdk, -canadian-cross and other combinations usually >>>> have too many differences to be worth the effort although it would be >>>> possible to make them work. >>> I'm not so sure about that, but we'll see. I should have some form of >>> canadian stuff working again shortly. >> You're unsure it would be possible to make them work of that its not >> worth the effort? > > Tom? > > Yesterday evening i was building a pristine master reference again and > saw that mpfr et al are (still) pretty outdated. > AFAIR i cannot mix BBCLASSEXTEND vs. old-fashioned recipes for one > package (didn't try if that's still true) so i'm, again, running into > the issue of what to do with older toolchains needing that canadian > stuff. I'm not too jazzed about the idea to touch the old toolchains > just because i want to have current gmp/mpc/mpfr/gcc (using CLASSEXTEND > nativesdk). So, how to proceed? So, where things stand right now (and have stood for a while) is that the existing canadian recipes simply don't work. We've made them work internally, and then moved them up to using nativesdk/etc. That's also been finished and the engineer in question is now working on making it work in OE.dev. But for now, don't let the existing canadian stuff (which is broken) get in the way of fixing up other stuff.
Patch
diff --git a/recipes/xz/xz.inc b/recipes/xz/xz.inc new file mode 100644 index 0000000..cc4f966 --- /dev/null +++ b/recipes/xz/xz.inc @@ -0,0 +1,9 @@ +DESCRIPTION = "XZ Utils is free general-purpose data compression software with high compression ratio. XZ Utils are the successor to LZMA Utils." +SECTION = "console/utils" +LICENSE = "Public Domain" +INC_PR = "r0" +S ?= "${WORKDIR}/xz-${PV}" +EXTRA_OECONF = "--enable-shared" +BBCLASSEXTEND = "native" + +inherit autotools diff --git a/recipes/xz/xz_4.999.9beta.bb b/recipes/xz/xz_4.999.9beta.bb new file mode 100644 index 0000000..8733023 --- /dev/null +++ b/recipes/xz/xz_4.999.9beta.bb @@ -0,0 +1,5 @@ +require xz.inc +PR = "${INC_PR}.0" +SRC_URI = "http://tukaani.org/xz/xz-${PV}.tar.bz2;name=xz" +SRC_URI[xz.md5sum] = "cc4044fcc073b8bcf3164d1d0df82161" +SRC_URI[xz.sha256sum] = "330312c4397608d8b7be362cc7edbfeafa6101614bc2164d816ea767656aa15c" diff --git a/recipes/xz/xz_git.bb b/recipes/xz/xz_git.bb new file mode 100644 index 0000000..8950a08 --- /dev/null +++ b/recipes/xz/xz_git.bb @@ -0,0 +1,6 @@ +S = "${WORKDIR}/git" +require xz.inc +PV = "git" +PR = "${INC_PR}.0" +SRC_URI = "git://ctrl.tukaani.org/xz.git;branch=master;protocol=git" +DEFAULT_PREFERENCE = "-1"