|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #52718 Simplifying Makefile.gcov?
Submitted: 2010-08-27 13:33 UTC Modified: 2019-09-25 08:42 UTC
From: Assigned: nikic (profile)
Status: Closed Package: Unknown/Other Function
PHP Version: 5.3SVN-2010-08-27 (SVN) OS: linux/unix
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
34 - 25 = ?
Subscribe to this entry?

 [2010-08-27 13:33 UTC]
Looks as if the current lcov/gcov implementation works by:

* collecting all 'interesting' files and copying/linking them
  over to a new directory lcov_data

* then removing files for which actually no coverage information
  should be generated, like bundled library sources

* finally running lcov and genhtml over the lcov_data copies

As far as i can tell the removal of bundled library stuff is the
only real reason for the copy/symlink step, or am i missing
something else there?

Assuming that this is really the only reason i'd like to propose
to use 'lcov --remove' for filtering out the bundled library stuff
instead and to run lcov and genhtml in place instead of the new
lcov_data subdir, so skipping the need for this extra directory
and the process needed to populate it.


* less complex (Makefile.gcov line count shrinks from 64 to 30)

* no duplication of information

* shows coverage info for a few file that the current implementation
  misses for some reason unknown to me yet, like

  * main/internal_functions.c
  * main/internal_functions_cli.c
  * ext/standard/
  * ext/standard/
  * Zend/zend_language_scanner.l
  * Zend/zend_ini_scanner.l


 * 'lcov --remove' is rather slow, as far as i can tell the copy&remove
   approach is a tad quicker ... the difference is not relevant when
   compared with the total time needed for a lcov analysis run though

 * genhtml still generates HTML files for files filtered out by
   'lcov --remove', so taking a bit longer to run, the files do not
   show up in any of the result overview pages though

So all in all i think the advantages justify a change while the
disadvantages are not blocking it.

The only thing that actually changes would be the ''
target in 'Makgefile.gcov', the simplified version would look
like this: lcov-test
    @echo "Generating $@"
    @$(LTP) --directory . --capture --base-directory . --output-file $@
    @echo "Stripping bundled libraries from $@"
    @for dir in ext/bcmath/libbcmath ext/fileinfo/libmagic ext/gd/libgd ext/mbstring/libmbfl ext/mbstring/oniguruma ext/pcre/pcrelib ext/pdo_sqlite/libsqlite ext/sqlite/libsqlite ext/sqlite3/libsqlite ext/xmlrpc/libxmlrpc ext/zip/lib; do \
        echo "... removing $$dir"; \
        $(LTP) --remove $@ $$dir/\* --output-file $@ ; \

Ideas, comments, any reasons *not* to commit this? 

Test script:
see Makefile.gcov implementation

Expected result:
LCOV report generated by patched PHP 5.3 "make lcov"

Actual result:
LCOV report generated by unpatched PHP 5.3 "make lcov"


make_lcov.diff (last revision 2010-08-27 11:40 UTC by hartmut dot holzgraefe at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-08-27 13:59 UTC]
Correct link for "Actual result" is
 [2010-08-30 19:11 UTC]
-Status: Open +Status: Assigned -Assigned To: +Assigned To: hholzgra
 [2010-08-30 19:11 UTC]
the lcov version on supports the flag, so this might be ok.
 [2017-10-24 07:02 UTC]
-Status: Assigned +Status: Open -Assigned To: hholzgra +Assigned To:
 [2019-09-25 08:42 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: nikic
 [2019-09-25 08:42 UTC]
This was implemented in
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Tue Nov 24 15:01:23 2020 UTC