Add code coverage via gcov/lcov to Orocos RTT. Patch against toolchain-2.3.
Results aren't terrible either ... :-) The low CORBA values may be as I couldn't get the corba tests to not segfault.
NB the default version of gcov/lcov on the Ubuntu Lynx install I used below, doesn't support branch coverage. Newer versions do. Also the link against gcov was required on Ubuntu, but not Mac OS X.
S
| Attachment | Size |
|---|---|
| 0001-cmake-Add-code-coverage.patch | 4.43 KB |
| coverage.jpeg | 37.44 KB |
[PATCH] Add code coverge
Hi Stephen,
On Sun, Mar 06, 2011 at 06:09:26PM +0100, S Roderick wrote:
> Add code coverage via gcov/lcov to Orocos RTT. Patch against toolchain-2.3.
>
> Results aren't terrible either ... :-) The low CORBA values may be
> as I couldn't get the corba tests to not segfault.
>
> NB the default version of gcov/lcov on the Ubuntu Lynx install I
> used below, doesn't support branch coverage. Newer versions do. Also
> the link against gcov was required on Ubuntu, but not Mac OS X.
Interesting! I wonder how the picture would look for a "standard"
application.
Could you send the figure in higher resolution, its barely readable.
Best regards
Markus
[PATCH] Add code coverge
On Mar 7, 2011, at 05:06 , Markus Klotzbuecher wrote:
> Hi Stephen,
>
> On Sun, Mar 06, 2011 at 06:09:26PM +0100, S Roderick wrote:
>> Add code coverage via gcov/lcov to Orocos RTT. Patch against toolchain-2.3.
>>
>> Results aren't terrible either ... :-) The low CORBA values may be
>> as I couldn't get the corba tests to not segfault.
>>
>> NB the default version of gcov/lcov on the Ubuntu Lynx install I
>> used below, doesn't support branch coverage. Newer versions do. Also
>> the link against gcov was required on Ubuntu, but not Mac OS X.
>
> Interesting! I wonder how the picture would look for a "standard"
> application.
>
> Could you send the figure in higher resolution, its barely readable.
>
> Best regards
> Markus
I had to reduce it to fit it thru the email slot. It originally barfed at 200kb ...
Try this ... otherwise I'll email hi-res directly.
CMake variable names (Was: [PATCH] Add code coverge)
On Sunday 06 March 2011 18:09:26 S Roderick wrote:
> Add code coverage via gcov/lcov to Orocos RTT. Patch against toolchain-2.3.
>
> Results aren't terrible either ... :-) The low CORBA values may be as I
> couldn't get the corba tests to not segfault.
>
> NB the default version of gcov/lcov on the Ubuntu Lynx install I used
> below, doesn't support branch coverage. Newer versions do. Also the link
> against gcov was required on Ubuntu, but not Mac OS X. S
Thanks for the patch. The only thing I'd like to change is the cmake variable
names, in a way that they are 'scoped' in meaningful groups.
Ie:
BUILD_....
PLUGINS_...
CORBA_...
MQUEUE_..
RTT_...
TYPES_
TESTS_...
INSTALL_
Ie, that they match the subdirectory/module they apply to (first selection
criterion), or have an effect on the build or install properties.
This would be required for every new cmake variable, and we would move the
existing ones gradually into that naming system.
If a cmake variable is exposed in the rtt-config.h file, it will be prefixed with
ORO_ in order to avoid name clashes. We don't use the ORO_ prefix in the cmake
options themselves.
Thoughts ?
Peter
CMake variable names (Was: [PATCH] Add code coverge)
On Mar 7, 2011, at 03:59 , Peter Soetens wrote:
> On Sunday 06 March 2011 18:09:26 S Roderick wrote:
>> Add code coverage via gcov/lcov to Orocos RTT. Patch against toolchain-2.3.
>>
>> Results aren't terrible either ... :-) The low CORBA values may be as I
>> couldn't get the corba tests to not segfault.
>>
>> NB the default version of gcov/lcov on the Ubuntu Lynx install I used
>> below, doesn't support branch coverage. Newer versions do. Also the link
>> against gcov was required on Ubuntu, but not Mac OS X. S
>
> Thanks for the patch. The only thing I'd like to change is the cmake variable
> names, in a way that they are 'scoped' in meaningful groups.
>
> Ie:
>
> BUILD_....
> PLUGINS_...
> CORBA_...
> MQUEUE_..
> RTT_...
> TYPES_
> TESTS_...
> INSTALL_
>
> Ie, that they match the subdirectory/module they apply to (first selection
> criterion), or have an effect on the build or install properties.
>
> This would be required for every new cmake variable, and we would move the
> existing ones gradually into that naming system.
>
> If a cmake variable is exposed in the rtt-config.h file, it will be prefixed with
> ORO_ in order to avoid name clashes. We don't use the ORO_ prefix in the cmake
> options themselves.
>
> Thoughts ?
>
> Peter
Are you saying to start scoping variables defined by FindXXX modules? If so, I'd say let's stick with the standard approach that every other FindXXX module follows. Otherwise I don't understand what you are getting at.
S
CMake variable names (Was: [PATCH] Add code coverge)
On Monday 07 March 2011 13:42:55 Stephen Roderick wrote:
> On Mar 7, 2011, at 03:59 , Peter Soetens wrote:
> > On Sunday 06 March 2011 18:09:26 S Roderick wrote:
> >> Add code coverage via gcov/lcov to Orocos RTT. Patch against
> >> toolchain-2.3.
> >>
> >> Results aren't terrible either ... :-) The low CORBA values may be as I
> >> couldn't get the corba tests to not segfault.
> >>
> >> NB the default version of gcov/lcov on the Ubuntu Lynx install I used
> >> below, doesn't support branch coverage. Newer versions do. Also the link
> >> against gcov was required on Ubuntu, but not Mac OS X. S
> >
> > Thanks for the patch. The only thing I'd like to change is the cmake
> > variable names, in a way that they are 'scoped' in meaningful groups.
> >
> > Ie:
> >
> > BUILD_....
> > PLUGINS_...
> > CORBA_...
> > MQUEUE_..
> > RTT_...
> > TYPES_
> > TESTS_...
> > INSTALL_
> >
> > Ie, that they match the subdirectory/module they apply to (first
> > selection criterion), or have an effect on the build or install
> > properties.
> >
> > This would be required for every new cmake variable, and we would move
> > the existing ones gradually into that naming system.
> >
> > If a cmake variable is exposed in the rtt-config.h file, it will be
> > prefixed with ORO_ in order to avoid name clashes. We don't use the ORO_
> > prefix in the cmake options themselves.
> >
> > Thoughts ?
> >
> > Peter
>
> Are you saying to start scoping variables defined by FindXXX modules? If
> so, I'd say let's stick with the standard approach that every other
> FindXXX module follows. Otherwise I don't understand what you are getting
> at. S
I was only refering to the ENABLE_COVERAGE option. For the FindXXX and general
cmake variables, we follow normal convention (for example CMAKE_PREFIX_PATH or
CMAKE_BUILD_TYPE etc remain as-is).
Peter
CMake variable names (Was: [PATCH] Add code coverge)
On Mar 7, 2011, at 08:04 , Peter Soetens wrote:
> On Monday 07 March 2011 13:42:55 Stephen Roderick wrote:
>> On Mar 7, 2011, at 03:59 , Peter Soetens wrote:
>>> On Sunday 06 March 2011 18:09:26 S Roderick wrote:
>>>> Add code coverage via gcov/lcov to Orocos RTT. Patch against
>>>> toolchain-2.3.
>>>>
>>>> Results aren't terrible either ... :-) The low CORBA values may be as I
>>>> couldn't get the corba tests to not segfault.
>>>>
>>>> NB the default version of gcov/lcov on the Ubuntu Lynx install I used
>>>> below, doesn't support branch coverage. Newer versions do. Also the link
>>>> against gcov was required on Ubuntu, but not Mac OS X. S
>>>
>>> Thanks for the patch. The only thing I'd like to change is the cmake
>>> variable names, in a way that they are 'scoped' in meaningful groups.
>>>
>>> Ie:
>>>
>>> BUILD_....
>>> PLUGINS_...
>>> CORBA_...
>>> MQUEUE_..
>>> RTT_...
>>> TYPES_
>>> TESTS_...
>>> INSTALL_
>>>
>>> Ie, that they match the subdirectory/module they apply to (first
>>> selection criterion), or have an effect on the build or install
>>> properties.
>>>
>>> This would be required for every new cmake variable, and we would move
>>> the existing ones gradually into that naming system.
>>>
>>> If a cmake variable is exposed in the rtt-config.h file, it will be
>>> prefixed with ORO_ in order to avoid name clashes. We don't use the ORO_
>>> prefix in the cmake options themselves.
>>>
>>> Thoughts ?
>>>
>>> Peter
>>
>> Are you saying to start scoping variables defined by FindXXX modules? If
>> so, I'd say let's stick with the standard approach that every other
>> FindXXX module follows. Otherwise I don't understand what you are getting
>> at. S
>
> I was only refering to the ENABLE_COVERAGE option. For the FindXXX and general
> cmake variables, we follow normal convention (for example CMAKE_PREFIX_PATH or
> CMAKE_BUILD_TYPE etc remain as-is).
Ok, that makes more sense. So are you proposing that ENABLE_COVERAGE becomes BUILD_ENABLE_COVERAGE?
Can you give a couple of other examples of changes you'd like to see?
S