[master] a65aa02 Enable optional lcov support

Dridi Boukelmoune dridi at varni.sh
Tue Apr 12 09:58:58 CEST 2016


> Answering your question, this is tied to GCC, yes.

That's not accurate, it is tied to gcov's file format.

I have successfully used lcov with clang in the past. But you might
run into issues when gcov changes its output file format [1] because
lcov and clang will catch up at different paces or need additional
flags.

> Have I mentioned how much I hate the entire autocrap thing for
> reducing portability instead of increasing it ?

The lcov plumbing I imported [2] are not even trying to be portable,
despite a fancy generic name of "ax_code_coverage" that only supports
lcov, gcc and gmake. I have looked closer at autotools after this lcov
fiasco and came to the conclusion that we are doing it wrong, probably
like most people (I'm looking at ax_code_coverage.)

For instance, we build libraries using libtool, and invoking a
one-liner LT_INIT would be enough to check a lot of Varnish's
toolchain because libtool requires at least C support. I'm not saying
that after reading some docs and macros implementations that I
suddenly find autotools great, but used right and if the planets align
(read not-recent-gnu-linux platforms) it could get less in the way and
possibly even become useful. That's a topic for another thread.

My last question was about reverting the commit. Since it wasn't
answered and since ax_code_coverage is still in the source tree,
should I assume it doesn't harm when disabled and can be left alone?

Dridi

[1] http://clang-developers.42468.n3.nabble.com/Code-coverage-on-clang-td4033066.html
[2] http://www.gnu.org/software/autoconf-archive/ax_code_coverage.html



More information about the varnish-commit mailing list