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

[Cillian O'Donnell]

On Fri, 18 May 2018, 07:46 Vijay Kumar Banerjee, <vijaykumar9597 at gmail.com>
wrote:

> 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
>

Cool, you should run it for the full testsuite and take a look at that
report (takes a while.. around 575 tests)

>
>> 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?
>

It's probably best to give some options to change the sets under test.

> Do we need to have a separate ini file for each set?
>

It can work either way, it's more a matter of which is the better design.

>
>> 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/dcf4cdfd/attachment-0002.html>