Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17741
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <002001c59d23$c697f1f0$0100a8c0@pc07653>
To: "John Coggeshall" <john@coggeshall.org>,
	<internals@lists.php.net>
References: <1123619893.8518.7.camel@localhost.localdomain>
Date: Tue, 9 Aug 2005 21:49:02 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] GCOV
From: nlopess@php.net ("Nuno Lopes")

Hi,

I've already had a change to test your patch (I've even have asked my 
university for a server to put ithe reports on-line).
I've also came into this issue, which happens because re2c is called in the 
wrong way (the output is printed to stdout, rather than directly to the 
file). Those files should be generated with 're2c -b -o output_file.c 
in_file.re'. (also: re2c should be called from the directory where the 
in_file.re is, so that it uses relatives paths)
Conclusion, you just need to regenerate the parsers correctly.

BTW, there was an error in your patch: it cleans the *.gcno files (which are 
generated at compile time) in cov_gen_clean() before running lcov, thus 
breaking the proccess.


Nuno


----- Original Message ----- 
From: "John Coggeshall" <john@coggeshall.org>
To: <internals@lists.php.net>
Sent: Tuesday, August 09, 2005 9:38 PM
Subject: [PHP-DEV] GCOV


> Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed.
> The changes are relatively minor and I've already run it past Andi. I'm
> trying to get around one last problem that maybe someone else can take
> care of:
>
> The basic issue is that our parsers have broken file/line preprocessor
> directives... since we're pre-generating these files and then committing
> them, things like #file and #line are breaking gcov because it's using
> them to look for source and the paths are from whomever committed them
> to begin with. I spoke with Andi about this at OSCON and we agreed that
> it's probably best when GCOV is enabled to strip those preprocessor
> directives out beforehand. Any other thoughts/comments? If no one has a
> better solution I'll commit the code later today.
>
> John