Hello Nuno, most of .re2c output can be overwritten anyway through commandline. For the others we probably need a sed call after generation.
marcus Monday, October 24, 2005, 9:23:01 PM, you wrote: > Paths can be made relative (at least re2c parsers, I don't know about > flex/bison). > This would just need a tweak in the makefile, to cd to the folder where the > 'file.re' is, instead of calling re2c with an absolute path. I'm sure Jani > can do this easily. > Without this, lcov stops in the first parser, thus breaking the coverage > report. > Nuno > P.S.: btw, the cvs version of lcov has a nice --show-legend option :) > ----- Original Message ----- >> If paths could be made relative, that's the ideal solution. Otherwise I >> agree with Marcus that when --enable-gcov is on the ./configure line we >> should regenerate the parsers and scanners to omit the debugging >> information. Perhaps it would be wise in this circumstance to also tack >> on a little warning stating this has occurred just to keep people from >> complaining. >> >> John >> >> On Fri, 2005-10-21 at 20:08 +0200, Marcus Boerger wrote: >>> Hello Jani, >>> >>> we should change LEX/YACC/RE2C in gcov mode to omit those lines >>> >>> marcus >>> >>> Thursday, October 20, 2005, 9:25:53 PM, you wrote: >>> >>> > You can get rid of the "bogus" #line lines with using >>> > the genfiles script. Don't even dream about getting rid >>> > of them in the files by using the -L or -l options for >>> > flex/bison!! >>> >>> > --Jani >>> >>> >>> > On Thu, 20 Oct 2005, Nuno Lopes wrote: >>> >>> >> >>> >>> john Wed Oct 19 20:18:26 2005 EDT >>> >>> >>> >>> Added files: >>> >>> /php-src Makefile.gcov gen_php_cov >>> >>> >>> >>> Modified files: >>> >>> /php-src NEWS configure.in >>> >>> Log: >>> >>> Implementing C-level Code coverage (--enable-gcov). >>> >>> >>> >>> o Requires LTP 1.4+ and libgcov >>> >> >>> >> Hello, >>> >> >>> >> As I've told you before, I had already tested your patch. It has the >>> >> problem >>> >> in the parsers that have bogus #line directives (but thats another >>> >> story). The >>> >> other problem is that you don't handle files with the same name. >>> >> >>> >> BTW, I have asked a server from my university for PHP automated >>> >> testing. They >>> >> told me that they would give me one, but I haven't received the code >>> >> yet >>> >> (waiting..). >>> >> I have already done a little cron job to automates the things. The >>> >> strongest >>> >> point in the little programs I've developed is a patch for >>> >> run-tests.php to >>> >> let them run with valgrind, to check for mem leaks in each test. It is >>> >> slow, >>> >> but works very well. This particular patch I would like to see in CVS >>> >> (see the >>> >> phpt_diff_w.txt file in my public cvs) >>> >> >>> >> the stuff is at: http://mega.ist.utl.pt/~ncpl/cvs/viewcvs.cgi/phpqa/ >>> >> >>> >> >>> >> Nuno Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
