After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 683211 - Port to gnome-common code coverage macros
Port to gnome-common code coverage macros
Status: RESOLVED FIXED
Product: gcr
Classification: Core
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-09-02 15:40 UTC by Philip Withnall
Modified: 2019-02-22 11:58 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Use gnome-common code coverage macros (3.15 KB, patch)
2012-09-02 15:42 UTC, Philip Withnall 		committed Details | Review

Description Philip Withnall 2012-09-02 15:40:48 UTC 
I’ve just committed support for code coverage to gnome-common (bug #606720). Here’s a patch to replace gcr’s home-grown gcov support with the gnome-common macro, which tidies up the build system a little.

This shouldn’t be applied until you’re ready to depend on gnome-common 3.6.0 (which hasn’t been released yet).
Comment 1 Philip Withnall 2012-09-02 15:42:11 UTC 
Created attachment 223203 [details] [review]
Use gnome-common code coverage macros
Comment 2 Stef Walter 2012-09-04 06:31:40 UTC 
Comment on attachment 223203 [details] [review]
Use gnome-common code coverage macros

Thanks! The one difference it seems is that our custom rules cleared the coverage data after generating a report. But I guess it's not the end of the world to do that manually.
Comment 3 Philip Withnall 2012-09-04 23:10:27 UTC 
(In reply to comment #2)
> The one difference it seems is that our custom rules cleared the
> coverage data after generating a report.

Is there any advantage to doing this?
Comment 4 Philip Withnall 2012-09-07 20:58:31 UTC 
Also, Bastien pointed out that we don’t need to wait for gnome-common to be released, as only people who run autoreconf will need the updated gnome-common.
Comment 5 Philip Withnall 2012-09-30 08:26:38 UTC 
It’s after the freeze now!
Comment 6 Stef Walter 2012-10-01 08:23:03 UTC 
(In reply to comment #3)
> (In reply to comment #2)
> > The one difference it seems is that our custom rules cleared the
> > coverage data after generating a report.
> 
> Is there any advantage to doing this?

The reason for this is that the linked in gcov code starts complaining loudly after rebuilding if the *.gcda files on disk don't match the newly generated binaries.

I guess clearing coverage data when building in a directory would accomplish the same thing. Have you seen this problem?

But in any case, I've branched gcr for gnome-3-6. Can you push this to master?
Comment 7 Philip Withnall 2012-10-03 12:36:59 UTC 
(In reply to comment #6)
> The reason for this is that the linked in gcov code starts complaining loudly
> after rebuilding if the *.gcda files on disk don't match the newly generated
> binaries.
> 
> I guess clearing coverage data when building in a directory would accomplish
> the same thing. Have you seen this problem?

Yes, but I always ignored it. My bad.

> But in any case, I've branched gcr for gnome-3-6. Can you push this to master?

Done! If you end up changing the rules to delete the *.gcda files, and you think it’s worthwhile upstreaming, please poke me or open a bug against gnome-common. Thanks.

commit a185f4f20f20776f6b0dcccb4f3eeba30941022a
Author: Philip Withnall <philip@tecnocode.co.uk>
Date:   Mon Aug 20 23:27:45 2012 +0100

    build: Use gnome-common code coverage macros
    
    Replace the existing home-grown gcov support with the new code coverage
    macro from gnome-common 3.6.0.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=683211

 Makefile.am   |  2 +-
 Makefile.decl | 17 ++++++++---------
 configure.ac  | 40 +++-------------------------------------
 3 files changed, 12 insertions(+), 47 deletions(-)