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.
[]
--
Best regards,
Paul mailto:[EMAIL PROTECTED]
_______________________________________________
Oe mailing list
[email protected]
https://www.handhelds.org/mailman/listinfo/oe
