On 8/4/2015 7:52 AM, Hermann Felbinger wrote:
Dear all! I'm currently working on a coverage report generator for RTEMS. In the current version a user has to set the absolute paths to the libraries, which are analyzed for coverage, in a config file, e.g., see [1]. A detailed explanation how to execute the test cases and how to invoke the generation of coverage reports, can be found in [2]. To eliminate the absolute paths to the analyzed libraries from the config file, I decided to add a command line parameter '--rtems-cpukit' which has to be set by the user, and points to the cpukit directory within the built rtems directory. An example for the usage of this parameter is: --rtems-cpukit=/home/hf/development/rtems/b-leon2/sparc-rtems4.11/c/leon2/cpukit/ Now relative paths to the libraries can be used in the config file, as shown in [3]. Do you think this is a useful solution to get rid of the absolute paths?
It would work and would be BSP independent. But it moves the path knowledge to the command line. Could it be done with just "/home/hf/development/rtems/b-leon2" and the user configuration file use @TARGET@/c/@BSP@/cpukit? Then the option could be --rtems-builddir or something similar. I am also thinking that as we move to waf, this might be easier to adapt without changes.
Could there be some libraries outside the cpukit directory that are analyzed for coverage?
It is possible but it wouldn't be something done on a regular basis.
Best, Hermann [1] https://github.com/hermann19829/rtems-tools/blob/master/tester/rtems/testing/coverage/symbolSets_pc386.config [2] http://socis2015rtems.blogspot.co.at/2015/07/build-rtems-and-execute-coverage.html [3] https://github.com/hermann19829/rtems-tools/blob/master/tester/rtems/testing/coverage/symbolSets.config
-- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
