Am 29.03.2013 13:54 schrieb "Diego Biurrun" <[email protected]>:
> > I don't think there is anything to improve here we are talking here
> > about an convenience target so that the developer does not have to
> > remember the exact lcov imposed workflow. The general idea is this:
> >
> > a) you instrument the complete libav codebase, including the avconv
> > binary, with profiling probes. This is done by the magic GCC compiler
> > flags.
> >
> > b) you run your workload. This may be 'make fate' on fate machines,
> > but I expect the regular developer to call avconv by hand on some more
> > or less random samples in his shell.
> >
> > c) this invocation will create some gcda files, which contain the data
> > produced by the implanted probes in the code from step a)
> >
> > d) lcov scans the build tree for these gcda files, and distills them
> > into a more or less compact format "coverage.info". This file can be
> > consumed by a number of front-ends, for instance, there is a jenkins
> > plugin that can consume it, but in this patch, I propose to use the
> > lcov tool, which produces HTML.
> >
> > Having said this, it does make sense to provide the coverage.info file
> > as makefile target, because you might want to have it for other uses
> > than lcov. For instance, I plan to play with a jenkins job that
> > produces a nicer HTML output and statistics over time, etc..
>
> So basically coverage.info should be updated every time a gcda file
> changes and not deleted immediately. I'll see if I can cook up
> something.
I don't think that's really worth the effort. Currently, the situation
is pretty predictably, but I'm happy to see your suggestion.
> > >> --- a/doc/developer.texi
> > >> +++ b/doc/developer.texi
> > >> @@ -550,6 +550,28 @@ why the expected result changed.
> > >>
> > >> +@subsection Visualizing Test Coverage
> > >> +
> > >> +The Libav build system provides means for visualizing the test coverage
> > >> +leveraging the coverage tools @code{gcov}/@code{lcov} in an easy manner.
> > >
> > > I'd say s/in an easy manner//, that's for the users to judge. But if
> > > you prefer, feel free to keep it.
> >
> > I'd prefer to keep it. your questions indicate that gcov/lcov is not
> > exactly straight-forward to use, so that side-note seems warranted to
> > me.
>
> I suggest:
>
> The Libav build system allows visualizing the coverage in an easy
> manner through the @code{gcov} / @code{lcov} tools.
coverage of what? fanboys on G+?
> > >> +This involves the following steps:
> > >> +
> > >> +@enumerate
> > >> +@item
> > >> + Configure to compile with instrumentation enabled:
> > >> + @code{configure --toolchain=gcov}.
> > >
> > > Use 4 spaces as indentation. I know that there is a list in that file
> > > that uses only 3, but let's not add more weirdness.
> >
> > fixed locally.
> >
> > Can you propose a patch that normalizes the indentation for the
> > texinfo files to avoid such copy mistakes in the future, please?
>
> I have something locally, will send in a few.
>
> > >> --- a/tests/Makefile
> > >> +++ b/tests/Makefile
> > >> @@ -123,6 +123,12 @@ $(FATE): $(FATE_UTILS:%=tests/%$(HOSTEXESUF))
> > >>
> > >> +coverage.info:
> > >> + lcov -d $(CURDIR) -b $(SRC_PATH) --capture -o $@
> > >> +
> > >> +lcov: coverage.info
> > >> + genhtml -o $(CURDIR)/lcov $<
>
> The online man page for genhtml says that the current directory is the default
> output location.
So? I do not want it in the current directory. And I really prefer
having full pathnames printed in verbose output, that's very
informative, espc. in out-of-tree builds.
regards,
Reinhard
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
