- 06 Oct, 2017 1 commit
-
-
Luca Boccassi authored
Solution: update it
-
- 09 May, 2016 1 commit
-
-
hitstergtd authored
Solution: This is an issue with the imported Autoconf M4 macro package for standardised code coverage builds, i.e. using --enable-code-coverage. The simplest way that I could find is to add a case statement that checks if the output of running `gcov -version` contains the "LLVM" keyword; if that is true then do not link with LIBGCOV as its neither required nor supported when using the GCOV frontend for LLVM; least not on Mac OS X. The case statement would also be the most portable. Moreover, using the "-version" argument instead of "-v" seems to be the best bet as that is supported by the normal GCOV and LLVM GCOV frontend. Upstream candidate - this solution should be improved by Autoconf M4 macro overlords and applied to the upstream M4 package; I could not find a suitable way to detect if LLVM GCOV is being used, except for the solution herein; this should also work on *BSD too.
-
- 02 May, 2016 1 commit
-
-
hitstergtd authored
Solution: Update them from the latest archive located at: git://git.savannah.gnu.org/autoconf-archive.git Hat-tip: @bluca
-
- 13 Mar, 2016 1 commit
-
-
Luca Boccassi authored
Solution: import ax_code_coverage.m4 from autoconf-archive and use it in configure.ac and Makefile.am in order to provide a make check-code-coverage target behind a --enable-code-coverage configure flag, that can be used to generate a gcov/lcov code coverage report. Depends on having gcov and lcov installed.
-