[PATCH] covoar.cc: Correct build path checks for multiple executables.

Cillian O'Donnell cpodonnell8 at gmail.com
Fri May 18 06:21:57 UTC 2018


On Thu, 17 May 2018, 21:32 Vijay Kumar Banerjee, <vijaykumar9597 at gmail.com>
wrote:

> hello,
>
> I have attached the html report !
>

Report looks good! Well done. Was that just for samples. Did the other
sections appear in the report if you click through the links?

Well it looks good but I hardcoded the paths, at least that gave the proper
> idea of what exactly needs to be done. Now I understand why
> --rtems-builddir stayed there for a long time , it makes the job simple .
>
> Here's a point that needs discussion :
>
> 1. the coverage.py in it's current state(before the updates I made today)
> tries to parse the score-symbols.ini file (class symbols_configuration()) ,
> which is not needed after the recent updates to covoar which makes it work
> from covoar itself. I have just removed that class for now .
>

Yeah there could definitely be some sections that might be completely
removed now. I left most things in because there's still some things
undecided. I'm not sure how we'll handle multiple sets now. Will we have
all sets in one .ini and create a new .ini for every different collection
of sets. Or will we define each set in one .ini each and pass multiple
.ini's to covoar. How will the user pick which sets he's interested in?
Pass names to coverage argument maybe

--coverage=score,core..etc

Chris when you redefined the config logic, how did imagine multiple sets
working?

>
> One thing can be done, which I think will solve parsing of the absolute
> path of the library as well. It is to implement the the logic that Chris
> used in covoar.cc , into the python script for coverage . Then we can do an
> os.path.abspath() for the absolute path and the extract the directory name
> from there for the html report from the same place. Can we do it that way ?
>

Sounds like a good plan. Definitely give it a shot.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180518/6c40be0c/attachment-0001.html>


More information about the devel mailing list