-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Sokolovsky schreef:
> Hello Koen,
>
> Sunday, July 9, 2006, 10:27:26 PM, you wrote:
>
>> Paul Sokolovsky schreef:
>
>>> -K_MAJOR = "2"
>>> -K_MINOR = "6"
>>> -K_MICRO = "15"
>>> -HHV = "0"
>>> +K_MAJOR ?= "2"
>>> +K_MINOR ?= "6"
>>> +K_MICRO ?= "15"
>>> +HHV ?= "0"
>>>
>>> Of course, ideally it should be given just CVS date and be able to
>>> infer corresponding kernel version from the checkout, but I'm not sure
>>> it can be done with OE, as there's going to be circular dependency -
>>> it must provide PV to be selected for specific build, and cannot (and
>>> of course shouldn't) do any actions (like checkout) unless it is
>>> selected.
>
>> A recipe with a floating cvs is is supposed to be valid against the scm
>> repo at that moment (give or take a day, thanks to timezones), so the
>> version should match what it has in cvs now, and you'll have no problem
>> developing.
>
>> However...
>
>> ... if you lock down a cvsdate (for whatever reason) this is only valid
>> if you keep the file 'stale'. By keeping the file 'stale' you prevent
>> people from working against latest cvs and run into the versioning and
>> therefore dependency problems you have.
>
> Oh, I guess I mention this: I actually wanted to make it follow CVS
> HEAD. But found that I can't (or don't know right idiom to do that)
> with BitBake 1.5 (r536 from 2006-06-01). I tried to use
>
> SRCDATE_handhelds-pxa-2.6 = ${DATE}
>
> Well, that builds for today, but when I try to build it tomorrow, I
> get the message that it cannot resolve today's version. Then for
> Familiar tree it just somehow selects jlime kernel to download. Well,
> I know why that happens - while the (new) cache is smart and fast, it
> caches specific snapshot of resolved PN&PVs. So, unless it is updated,
> it indeed want find tomorrow's floating date. Given the strange effect
> this has, I just set static date before submitting a patch.
>
>
>
>
> Otherwise I got that idea - you don't want a machine config with
> specific SRCDATE. Even if it's new machine, support for which in
> development and config for which very well will be fixed off that bug
> in near future. Well, no problem, the rules are rules. But what I'm
> arguing for is having infrastructure in place which will allow people
> to do those builds for themselves out of the box - let the configs
> they use for this stay forever in their local trees, but it'll still
> be a good help for them, as each of them won't need to reinvent the
> wheel in each own local tree - OE pretty well can provide teh tools
> for this, without regressing its other usages.
Right. It is unacceptable to put the '?=' patch in OE, but there is a
different and vastly better way:
Add a little python snippet that does something like this:
if(srcdate > 20060101) PV=2.6.1 KMAJOR=2.....
if(srcdate > 20060202) PV=2.6.2
if(srcdate > 20060303) PV=2.6.3
...
that would solve problems you might have in a much nicer way and makes
it easier to debug where all those PV changes are coming from.
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEs0d7MkyGM64RGpERAryeAJ9degaMSDH8rd7c3cFZZvzLuKPVtgCgnhdP
7wb+mKYUuJgnHXrJXEBYo5Y=
=6CKj
-----END PGP SIGNATURE-----
_______________________________________________
Oe mailing list
[email protected]
https://www.handhelds.org/mailman/listinfo/oe
