Re: 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.

[Bruce Ashfield <bruce.ashfield@windriver.com>]

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
>