# GCOV - Thread: https://externals.io/message/17738 - Original archive: https://news-web.php.net/php.internals/17738 - Started by John Coggeshall on 2005-08-09T20:38:13+00:00 - Messages: 12 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #17738 — John Coggeshall — 2005-08-09T20:38:13+00:00 URL: https://externals.io/message/17738#17738 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 --- ## #17739 — Wez Furlong — 2005-08-09T20:40:55+00:00 URL: https://externals.io/message/17738#17739 · In reply to: #17738 IIRC, we have a script that does this already for our release tarballs; should save some effort. --Wez. > 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 --- ## #17740 — John Coggeshall — 2005-08-09T20:44:01+00:00 URL: https://externals.io/message/17738#17740 · In reply to: #17739 I also wrote one, i don't care which we use... it's a 5 line shell script :) > IIRC, we have a script that does this already for our release > tarballs; should save some effort. > > --Wez. > > > > […] --- ## #17741 — Nuno Lopes — 2005-08-09T20:49:02+00:00 URL: https://externals.io/message/17738#17741 · In reply to: #17738 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" To: 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 --- ## #17742 — Marcus Boerger — 2005-08-09T20:50:04+00:00 URL: https://externals.io/message/17738#17742 · In reply to: #17740 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: > I also wrote one, i don't care which we use... it's a 5 line shell > script :) > > > […] --- ## #17744 — Marcus Boerger — 2005-08-09T20:55:40+00:00 URL: https://externals.io/message/17738#17744 · In reply to: #17741 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" > To: > Sent: Tuesday, August 09, 2005 9:38 PM > Subject: [PHP-DEV] GCOV > > […] Best regards, Marcus --- ## #17745 — Wez Furlong — 2005-08-09T20:55:43+00:00 URL: https://externals.io/message/17738#17745 · In reply to: #17741 JFYI: -o doesn't work on all versions of re2c --Wez. > 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" > To: > Sent: Tuesday, August 09, 2005 9:38 PM > Subject: [PHP-DEV] GCOV > > > > […] --- ## #17746 — Marcus Boerger — 2005-08-09T20:58:55+00:00 URL: https://externals.io/message/17738#17746 · In reply to: #17745 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. > > > […] Best regards, Marcus --- ## #17747 — George Schlossnagle — 2005-08-09T20:59:32+00:00 URL: https://externals.io/message/17738#17747 · In reply to: #17745 > 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 > > --Wez. > > > > > […] > > -- > > > > George Schlossnagle -- Vice President of Engineering -- OmniTI Computer Consulting -- http://www.omniti.com --- ## #17748 — Wez Furlong — 2005-08-09T21:01:56+00:00 URL: https://externals.io/message/17738#17748 · In reply to: #17746 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. > 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: > > > […] > > > […] > > > […] > > > Best regards, > Marcus --- ## #17749 — Marcus Boerger — 2005-08-09T21:08:03+00:00 URL: https://externals.io/message/17738#17749 · In reply to: #17748 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. > > > […] Best regards, Marcus --- ## #17752 — John Coggeshall — 2005-08-09T21:30:09+00:00 URL: https://externals.io/message/17738#17752 · In reply to: #17741 > 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