Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » GCOV »

GCOV

php.internals

John Coggeshall

21 years ago
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

Wez Furlong

21 years ago
IIRC, we have a script that does this already for our release tarballs; should save some effort. --Wez. On 8/9/05, John Coggeshall <john@coggeshall.org> wrote:

John Coggeshall

21 years ago
I also wrote one, i don't care which we use... it's a 5 line shell script :) On Tue, 2005-08-09 at 16:40 -0400, Wez Furlong wrote:

Marcus Börger

21 years ago
Hello John, for the .re ones i could simply release re2c 0.9.10 and you use the new switch we especially made for that. If i knew we were going for 5.1 i had probably done that at OSCON but i didn't see any action required until just now. best regards marcus Tuesday, August 9, 2005, 10:44:01 PM, you wrote:

Nuno Lopes

21 years ago
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

Marcus Börger

21 years ago
Hello Nuno, that's also absolutley correct for most .re'S. Tuesday, August 9, 2005, 10:49:02 PM, you wrote:
> 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.
Best regards, Marcus

Wez Furlong

21 years ago
JFYI: -o doesn't work on all versions of re2c --Wez. On 8/9/05, Nuno Lopes <nlopess@php.net> wrote:

Marcus Börger

21 years ago
Hello Wez, just to remind you: you are the only one using an old unsupport version that doesn't come with -o. marcus Tuesday, August 9, 2005, 10:55:43 PM, you wrote:
> JFYI: -o doesn't work on all versions of re2c
> --Wez.
> On 8/9/05, Nuno Lopes <nlopess@php.net> wrote: >> 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.
Best regards, Marcus

Wez Furlong

21 years ago
No, I'm not (both not the only one using an older version, nor am I necessarily using an older version). Until someone points out a re2c bug that actually impacts PHP, I'm in no rush to run around upgrading more than 20 machines. --Wez. On 8/9/05, Marcus Boerger <helly@php.net> wrote:

Marcus Börger

21 years ago
Hello Wez, i fixed some bugs in re2c since -o was added. Some of those were serious ones. Whether they affect pdo i cannot tell but for one issue i know that it may affect ext/standard usage (depending on the compiler iirc). Maybe jani can recall the reasons why and when we increased the re2c version requirement. marcus Tuesday, August 9, 2005, 11:01:56 PM, you wrote:
> No, I'm not (both not the only one using an older version, nor am I > necessarily using an older version).
> Until someone points out a re2c bug that actually impacts PHP, I'm in > no rush to run around upgrading more than 20 machines.
> --Wez.
> On 8/9/05, Marcus Boerger <helly@php.net> wrote: >> Hello Wez, >> >> just to remind you: you are the only one using an old unsupport version >> that doesn't come with -o. >> >> marcus >> >> Tuesday, August 9, 2005, 10:55:43 PM, you wrote: >> >> > JFYI: -o doesn't work on all versions of re2c >> >> > --Wez. >> >> > On 8/9/05, Nuno Lopes <nlopess@php.net> wrote: >> >> 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. >> >> >> Best regards, >> Marcus >> >>
Best regards, Marcus

George Schlossnagle

21 years ago
On Aug 9, 2005, at 4:55 PM, Wez Furlong wrote:
> JFYI: -o doesn't work on all versions of re2c
Since when has PHP been concerned about not requiring the most-most recent version of a library, let alone a development tool? George <still sore about having to upgrade libxml2 every couple weeks>
> > --Wez. > > On 8/9/05, Nuno Lopes <nlopess@php.net> wrote: > >> 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 >>> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
George Schlossnagle -- Vice President of Engineering -- OmniTI Computer Consulting -- http://www.omniti.com

John Coggeshall

21 years ago
On Tue, 2005-08-09 at 21:49 +0100, Nuno Lopes wrote:
> 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.
Opps. I'll fix that when I commit. As soon as we get the parsers fixed up I'll make some final tweaks and get it in CVS John