[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ltp-coverage
Subject:    Re: [Ltp-coverage] A patch for lcov to handle source tree paths
From:       Lars Marowsky-Bree <lmb () novell ! com>
Date:       2010-10-22 8:48:19
Message-ID: 20101022084819.GM31993 () suse ! de
[Download RAW message or body]

On 2010-10-22T09:20:16, Peter Oberparleiter <oberpar@linux.vnet.ibm.com> wrote:

> >../include/crm/common/util.h:cannot open source file
> >../include/crm/crm.h:cannot open source file
> >../include/crm/ais.h:cannot open source file
> >messages.c:cannot open source file
> >Finished .info-file creation
> 
> Is all of the source code installed at all on the machine on which
> lcov is run?

Yes; the base directory points to the top of the (complete) source
tree.

> >For some reason, it strips out the "pacemaker" bit.
> 
> /usr/src/debug/pacemaker + ../include/crm/ais.h =
> /usr/src/debug/include/crm/ais.h
> 
> One explanation could be that the build system of your project uses
> different "base directories", i.e. when compiling, the current
> working directory of gcc is not always the same.

Ah, yes. automake etc probably do that to us.

> This approach, together with gcc's profiling mechanism which stores
> relative source code paths in object files results in symptoms similar
> to the ones that you are seeing.

Yes; in fact, I've considered working on this by modifying the gcc suite
directly. I'm contemplating of extending the debuginfo/debugsource
packages so as to be generally useful for profiling/coverage too, and
that would imply directly resolving relative paths, stripping out the
build source root path, and replacing it with the intended debugsource
package that'd be installed on the running system.

(Without having the user figure out GCOV_PREFIX_STRIP etc.)

> There are several ways to work around this problem:
> 
> 1. use lcov once for each base directory, e.g. assuming your code
> lives in /usr/src/project and has two components "one" and "two"

Yes, this is however rather annoying for a generic approach.

The patch for genhtml though seems to also resolve this, since it does
effectively the above - and I played with doing it in lcov, but somehow
failed. Probably I'm doing a stupid mistake somewhere along the line ;-)

> 2. during compilation, change all relative paths to absolute paths
> (e.g. include paths, etc.).

Yes, that's essentially the direction of thought I've also been taking.

Frankly, gcov's approach isn't very well suited for packaging; it seems
geared towards mostly a developer tool (i.e., running from the build
directory).


Regards,
    Lars

-- 
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde


------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Ltp-coverage mailing list
Ltp-coverage@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-coverage

[prev in list] [next in list] [prev in thread] [next in thread]