[cmake-developers] Support for coverage.py coverage on the topic stage

[Rolf Eike Beer]

Am Sonntag, 29. September 2013, 14:22:02 schrieben Sie:
> Eike,
> 
> This is fantastic feedback. Thanks!
> 
> I've responded to specific issues inline.
> 
> TL;DR: I fixed a lot of these points. This should be closer to
> merge-ability.
> > Am Freitag, 27. September 2013, 11:30:52 schrieb Patrick Reynolds:
> > > Hi folks,
> > > 
> > > I just pushed a topic to the stage that adds support for coverage.py
> > > python
> > > coverage. It actually should work for anything the exports cobertura
> > > coverage.xml files.
> > > 
> > > The topic is here:
> > > 
> > > http://public.kitware.com/gitweb?p=stage/cmake.git;a=shortlog;h=refs/hea
> > > ds/A dd-coverage.py-Coverage
> > 
> > You are doomed! Now that you want to introduce a new coverage handler I'll
> > complain as long until you add a testcase for it, i.e. putting a sample
> > output file in the Tests/ directory and verify that CTest will generate
> > the expected results ;)
> 
> Challenge accepted! The test is added and I pushed the updated branch:

I would prefer if you could start with a Tests/Coverage/ directory (or 
something similar) as the other coverage handlers also need such tests and 
this avoids a later move. Brad?

> http://public.kitware.com/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/A
> dd-coverage.py-Coverage
> > But there are some things about your code and even about older code.
> > First,
> > you do not set error from cont.error in
> > cmCTestCoverageHandler::ProcessHandler().
> 
> Fixed on the aforementioned branch.

I don't see it.

> > Second, this whole gathering code there will badly fail once 2 coverage
> > systems are present and the second one gives an error. Say gcov finds 2
> > files. Then python has an error, returns -1. The file count is 1, no
> > error is propagated. This is not your fault, but please fix this in one
> > commit first before adding your new handler. And maybe make this block
> > from gcov to mumps somehow use an array, vector, list, or something and
> > just iterate over it, so you only have to add your handler into the
> > array.
> 
> Hmmm. I agree with you on this one; however, I think this may be beyond the
> scope of my contribution. If it's okay with the community, I would like to
> add a bug in Mantis for this overall and treat it as a separate topic.

Yes, probably. Brad, any preferences on how this should be done?

> > Another important question: can python handle the situation where 2 test
> > programs run in parallel and want to write to the coverage file? Or will
> > they just happily trash each others results? That's a problem I fixed in
> > 2.8.12 which would have happened for all other coverage generators.
> 
> I have not verified this experimentally, but coverage.py claims to support
> this through there '-p', parallel option.

Let's hope the best ;)

> I'll leave this one to folks who are better versed in the arcane art of
> Bullseye...

Does anyone still use this? ;)

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130929/337c6527/attachment.sig>