<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 15, 2018 at 12:58 AM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14/9/18 11:18 pm, Sebastian Huber wrote:<br>
> ---<br>
>  cpukit/Makefile.am                    | 79 ++++++++++++++++++++++++++++++++++-<br>
>  cpukit/<a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a>                   |  1 -<br>
>  cpukit/sapi/Makefile.am               | 63 ----------------------------<br>
>  cpukit/{sapi => }/vc-key.sh           |  0<br>
>  cpukit/{sapi => }/<a href="http://version-vc-key.h.in" rel="noreferrer" target="_blank">version-vc-key.h.in</a> |  0<br>
>  cpukit/wrapup/Makefile.am             |  2 +-<br>
>  6 files changed, 79 insertions(+), 66 deletions(-)<br>
>  delete mode 100644 cpukit/sapi/Makefile.am<br>
>  rename cpukit/{sapi => }/vc-key.sh (100%)<br>
>  rename cpukit/{sapi => }/<a href="http://version-vc-key.h.in" rel="noreferrer" target="_blank">version-vc-key.h.in</a> (100%)<br>
<br>
Could you please explain why you are performing this merge?<br>
<br>
I am not against such a change however I would like to understand what the plan<br>
is and where this is going?<br>
<br>
The coverage tool and covoar work is using the internally built libraries to<br>
group functionality, for example score. If the cpukit build is completely<br>
fattened I think that tool may need to change to manage the grouping.<br></blockquote><div><br></div><div><br></div><div>The coverage analysis has always assumed that the directories and the</div><div>sub-libraries created imply areas of functionality that a developer would</div><div>like to know the coverage of independently of other areas. For example,</div><div>should the score, fatfs, and shell be lumped into one coverage report</div><div>or would it be IMO preferable to generate them on each area?</div><div><br></div><div>We need to recognize that some code analysis needs to know the logical</div><div>grouping of code. How do you propose this happen when the information</div><div>implicit in the sub-libraries is lost?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>