Proposed Reorganization of Coverage Reporting
joel.sherrill at OARcorp.com
Sun Nov 18 22:55:24 UTC 2012
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:
>> 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.
More information about the users