Proposed Reorganization of Coverage Reporting

[Joel Sherrill]

By bucket, I meant category or collection of symbols. Now we have core and "everything". I am proposing adding a report set basically by source directory.

This would still be in addition to the -O2/-Os and posix enable/disable variations.

It will not add to the build or test execution time. It will add to the report generation time. All views/categories can be generated from a single run.



Chris Johns <chrisj at rtems.org> wrote:

>Joel Sherrill wrote:
>> Hi
>>
>> RIght now, we only have two "buckets" of code when we
>> report coverage:
>>
>> + core - sapi, rtems, score, and posix directories
>> + developmental - core + ~15 cpukit directories
>>
>> I am proposing to add more buckets and remain
>> developmental to "All" or something someone suggests.
>>
>> The idea came up when trying to focus on the status
>> of the RFS coverage. When it had low coverage, it pulled
>> down the entire developmental number but as we worked
>> on improving the coverage, it was clear we wanted a
>> very focused view.
>>
>> Any thoughts?
>>
>
>I am not sure what you mean by a "bucket". Is this something managed at 
>the processing of the simulator output or when the report is generated ?
>
>If it is when the simulator output is processed why mix 2 different 
>views of the structure in RTEMS ? That is, why not "bucket" based on 
>what the code is in RTEMS. This would mean RFS would be in the RFS 
>bucket. The report can be then be generated from a specific set of 
>"buckets" that interest you.
>
>Chris