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

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Fri May 18 06:46:34 UTC 2018


On Fri, 18 May 2018, 11:52 Cillian O'Donnell, <cpodonnell8 at gmail.com> wrote:

>
>
> 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?
>
yes it was for samples and yes the links are working .

>
> 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
>
The script used to treat it like a collection of sets. I was thinking of
running a loop over all the keys under a tag [symbol-sets] and getting
their respective libraries .
Is it for the user to decide which sets to use?
Do we need to have a separate ini file for each set?

>
> 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.
>
it would be good if it works out, but again , the main challenge is the
path to build directory. :p
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180518/1e20447e/attachment-0002.html>


More information about the devel mailing list