Re: [PHP-CVS] cvs: php-src / Makefile.gcov
On 2008/07/30, at 15:56, Pierre Joye wrote: hi, On Wed, Jul 30, 2008 at 2:43 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: Hello Pierre, but we are not creating tests for any of these, actually all of these have their own testing system which in most case is not even bundeled or executable through PHP. So the only way out is to run their respective test systems by bundling them and integrating them into our build and gcov runs. However our gcov runs are highly specialized. So I do not see any point in doing that. Nor do I see a point in having any of these pull pown or percentage and in that way making us look worse then we are and even keep us from increasing our limits and goals. It may be true for pcre or mbstring's libs not for GD for the reasons I stated earlier. I got the same opinion as Marcus's for mbstring and PCRE, while I doubt bundling three different regex libraries is a good idea. The maintainers know better about the treatment of the other bundled libraries, I guess. Moriyoshi Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
On Wed, 30 Jul 2008, Marcus Boerger wrote: > Wednesday, July 30, 2008, 9:50:18 AM, you wrote: > > > On Tue, 29 Jul 2008, Pierre Joye wrote: > > >> On Tue, Jul 29, 2008 at 10:10 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: > >> > helly Tue Jul 29 08:10:31 2008 UTC > >> > > >> > Modified files: > >> >/php-srcMakefile.gcov > >> > Log: > >> > - Exclude bundled libs from gcov processing > >> > >> Why? It makes sense to keep it, for example for GD as the lib and > >> php are well integrated. > > > I'd like the same for libmagic (very new, unknown) and timelib > > (because it's well integrated). > > timelib, yeah unknown, yeah new, so is it us to write a test system > for them? no! Uhm yes - we need to support it - libmagic requires most likely a fork. And what does it matter if there are a few more libs in here?! > datelib, cool, great, damn well tested, so no need to test again. Or do you > want all your libdate tests to php? Yes, because the behavior in PHP is some times slightly different -- and should be. regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
Hello Derick, Wednesday, July 30, 2008, 9:50:18 AM, you wrote: > On Tue, 29 Jul 2008, Pierre Joye wrote: >> On Tue, Jul 29, 2008 at 10:10 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> > helly Tue Jul 29 08:10:31 2008 UTC >> > >> > Modified files: >> >/php-srcMakefile.gcov >> > Log: >> > - Exclude bundled libs from gcov processing >> >> Why? It makes sense to keep it, for example for GD as the lib and php >> are well integrated. > I'd like the same for libmagic (very new, unknown) and timelib (because > it's well integrated). timelib, yeah unknown, yeah new, so is it us to write a test system for them? no! datelib, cool, great, damn well tested, so no need to test again. Or do you want all your libdate tests to php? > regards, > Derick Best regards, Marcus -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
Hello Pierre, Wednesday, July 30, 2008, 9:33:10 AM, you wrote: > Hi, > On Wed, Jul 30, 2008 at 9:18 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> So you are saying that PHP can use GD in a way that makes it brake which is >> not covered by GD's testing? > That's not what I'm saying. First, GD in php is not the same library > that you have in libgd.org and is better integrated with php (not > possible to do so using an external library). Secondly, almost all > tests available in libgd's tests suite have been ported or are in the > process to be ported to php. >> Sounds very bad, actually having GD a PHP >> project makes it a really special case. > It is irrelevant in this case, they are not the same. >> So if you want to and can find a >> good way of integrating GD testing than I am happy to address that. > It is the case already. >> Unless >> you deliver a solution that goes for our goal which is 90% required for >> green in the near future I however have to exclude it. > As I agree that good coverage is a noble cause. I prefer to have a > slightly lower visible coverage and get the code actually covered > marked as such. Please revert this change for GD. So it appears that gd is in the exact same situation as ext/dba/libcdb which I explicitly ported for PHP. Now that one has 82.1% coverage so obviously has no larger non PHP chunks and also seems to be triggered in quite enough ways. So I didn't pull it. My intention was to drop libs that hopefully have there own testing infrastructure and don't get fully triggered by PHP testing. Best example is pcre. Where it simply doesn't make sense to write phpt tests that trigger all those edge cases from PHP. So we rather exclude that from our calculations as we don't even have the intention to test those. Best regards, Marcus -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
On Tue, 29 Jul 2008, Pierre Joye wrote: > On Tue, Jul 29, 2008 at 10:10 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: > > helly Tue Jul 29 08:10:31 2008 UTC > > > > Modified files: > >/php-srcMakefile.gcov > > Log: > > - Exclude bundled libs from gcov processing > > Why? It makes sense to keep it, for example for GD as the lib and php > are well integrated. I'd like the same for libmagic (very new, unknown) and timelib (because it's well integrated). regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
Hi, On Wed, Jul 30, 2008 at 9:18 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: > So you are saying that PHP can use GD in a way that makes it brake which is > not covered by GD's testing? That's not what I'm saying. First, GD in php is not the same library that you have in libgd.org and is better integrated with php (not possible to do so using an external library). Secondly, almost all tests available in libgd's tests suite have been ported or are in the process to be ported to php. > Sounds very bad, actually having GD a PHP > project makes it a really special case. It is irrelevant in this case, they are not the same. > So if you want to and can find a > good way of integrating GD testing than I am happy to address that. It is the case already. > Unless > you deliver a solution that goes for our goal which is 90% required for > green in the near future I however have to exclude it. As I agree that good coverage is a noble cause. I prefer to have a slightly lower visible coverage and get the code actually covered marked as such. Please revert this change for GD. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
Hello Pierre, Wednesday, July 30, 2008, 8:56:41 AM, you wrote: > hi, > On Wed, Jul 30, 2008 at 2:43 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> Hello Pierre, >> >> but we are not creating tests for any of these, actually all of these >> have their own testing system which in most case is not even bundeled or >> executable through PHP. So the only way out is to run their respective test >> systems by bundling them and integrating them into our build and gcov runs. >> However our gcov runs are highly specialized. So I do not see any point in >> doing that. Nor do I see a point in having any of these pull pown or >> percentage and in that way making us look worse then we are and even keep >> us from increasing our limits and goals. > It may be true for pcre or mbstring's libs not for GD for the reasons > I stated earlier. So you are saying that PHP can use GD in a way that makes it brake which is not covered by GD's testing? Sounds very bad, actually having GD a PHP project makes it a really special case. So if you want to and can find a good way of integrating GD testing than I am happy to address that. Unless you deliver a solution that goes for our goal which is 90% required for green in the near future I however have to exclude it. Best regards, Marcus -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
hi, On Wed, Jul 30, 2008 at 2:43 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: > Hello Pierre, > > but we are not creating tests for any of these, actually all of these > have their own testing system which in most case is not even bundeled or > executable through PHP. So the only way out is to run their respective test > systems by bundling them and integrating them into our build and gcov runs. > However our gcov runs are highly specialized. So I do not see any point in > doing that. Nor do I see a point in having any of these pull pown or > percentage and in that way making us look worse then we are and even keep > us from increasing our limits and goals. It may be true for pcre or mbstring's libs not for GD for the reasons I stated earlier. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
Hello Pierre, but we are not creating tests for any of these, actually all of these have their own testing system which in most case is not even bundeled or executable through PHP. So the only way out is to run their respective test systems by bundling them and integrating them into our build and gcov runs. However our gcov runs are highly specialized. So I do not see any point in doing that. Nor do I see a point in having any of these pull pown or percentage and in that way making us look worse then we are and even keep us from increasing our limits and goals. marcus Tuesday, July 29, 2008, 10:17:15 AM, you wrote: > hi, > On Tue, Jul 29, 2008 at 10:10 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> helly Tue Jul 29 08:10:31 2008 UTC >> >> Modified files: >>/php-srcMakefile.gcov >> Log: >> - Exclude bundled libs from gcov processing > Why? It makes sense to keep it, for example for GD as the lib and php > are well integrated. > Cheers, Best regards, Marcus -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
hi, On Tue, Jul 29, 2008 at 10:10 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: > helly Tue Jul 29 08:10:31 2008 UTC > > Modified files: >/php-srcMakefile.gcov > Log: > - Exclude bundled libs from gcov processing Why? It makes sense to keep it, for example for GD as the lib and php are well integrated. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov
Thanks Rasmus! The SoC student was becoming crazy with this problem :) rasmus Fri Jun 9 23:46:43 2006 UTC Modified files: /php-src Makefile.gcov Log: Patch from Nuno http://cvs.php.net/viewcvs.cgi/php-src/Makefile.gcov?r1=1.13&r2=1.14&diff_format=u Index: php-src/Makefile.gcov diff -u php-src/Makefile.gcov:1.13 php-src/Makefile.gcov:1.14 --- php-src/Makefile.gcov:1.13 Tue Mar 21 18:17:03 2006 +++ php-src/Makefile.gcov Fri Jun 9 23:46:43 2006 @@ -37,6 +37,9 @@ if test -f "$(top_srcdir)/$$y.c"; then \ ln -f -s $(top_srcdir)/$$y.c lcov_data/$$y.c; \ fi; \ + if test -f "$(top_srcdir)/$$y.h"; then \ + ln -f -s $(top_srcdir)/$$y.h lcov_data/$$y.h; \ + fi; \ if test -f "$(top_srcdir)/$$y.re"; then \ ln -f -s $(top_srcdir)/$$y.re lcov_data/$$y.re; \ fi; \ -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / Makefile.gcov configure.in
On 08.12.2005 19:00, Ilia Alshanetsky wrote: - ltp_version_list="1.4" + ltp_version_list="1.5" Once you've made 1.5 as a requirement, it would make sense to add --legend to the genhtml command. I'll commit it if there are no objections. Index: Makefile.gcov === RCS file: /repository/php-src/Makefile.gcov,v retrieving revision 1.4.2.7 diff -u -p -d -r1.4.2.7 Makefile.gcov --- Makefile.gcov 8 Dec 2005 16:00:28 - 1.4.2.7 +++ Makefile.gcov 8 Dec 2005 18:31:42 - @@ -61,7 +61,7 @@ php_lcov.info: lcov-test lcov-html: php_lcov.info @echo "Generating lcov HTML" - @$(LTP_GENHTML) --no-prefix --output-directory lcov_html/ --title "PHP Code Coverage" --show-details php_lcov.info + @$(LTP_GENHTML) --no-prefix --output-directory lcov_html/ --title "PHP Code Coverage" --legend --show-details php_lcov.info lcov-clean: rm -f php_lcov.info -- Wbr, Antony Dovgal -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
