On 12-08-23 01:28 PM, Markus Hubig wrote:
On Thu, Aug 23, 2012 at 12:26:30PM -0400, Bruce Ashfield wrote:
On 12-08-23 12:18 PM, Markus Hubig wrote:
On Thu, Aug 23, 2012 at 09:31:15AM -0400, Bruce Ashfield wrote:
On 12-08-23 09:24 AM, Markus Hubig wrote:
<snipp>
Surprisingly if I remove the *.cfg files from the SRC_URI
| SRC_URI_append_portuxg20 = "\
| file://portuxg20-standard.scc \
| file://portuxg20-preempt-rt.scc \
| file://portuxg20.scc \
| "
|
| SRC_URI_append_stamp9g20 = "
| file://stamp9g20-standard.scc \
| file://stamp9g20-preempt-rt.scc \
| file://stamp9g20.scc \
it also works ...
Yes, and I can explain this part. When a .scc file is detected, the
entire directory contents are propagated to the kernel build, since
.scc files can refer to patches, configs, etc, and some elements are
optional, they are all made available.
So if you reference .cfgs and patches in your .scc files, you don't
need them in the SRC_URI, just the .scc file.
Is it possible that if I remove the *.cfg files, bitbake no longer tracks
changes inside this files and will not rebuild the related packages from
scratch with:
If the checksums are over the elements in the SRC_URI, then that would
be true, but I'm not a checksum or fetcher expert.
repeating a .cfg really should be safe, just a bit verbose, I'll retest
that here to see if something broke.
My workflow never hits any problems with not rebuilding, but I can also
check that. If necessary, listing the files, or another technique to get
the checksum'd would be advisable. I'll look into that as well.
Cheers,
Bruce
| bitbake -fc clean linux-yocto
| bitbake linux-yocto
Cheers, Markus
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
