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