Gregory Stark wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> > I have uploaded an example run here:
> > http://developer.postgresql.org/~petere/coverage/
> >
> > Current test coverage is about 66% overall.
>
> With some pretty glaring gaps: 0% coverage of geqo, 0% coverage of logtape
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I have uploaded an example run here:
> http://developer.postgresql.org/~petere/coverage/
>
> Current test coverage is about 66% overall.
With some pretty glaring gaps: 0% coverage of geqo, 0% coverage of logtape
which implies no tuplesorts are spilli
Michelle Caisse wrote:
Thanks, I'll take a look at these issues.
I have committed your patch with some rework that mainly addresses the
concerns also found by Alvaro with regard to cleaning and dependency
handling. I have renamed the out target to coverage-html, to be more in
line with our
Thanks, I'll take a look at these issues.
-- Michelle
Alvaro Herrera wrote:
Michelle Caisse wrote:
I've attached a patch that allows the generation of code coverage
statistics. To test it, apply the patch, then:
autoconf
./configure --enable-coverage
make
make check (or execute any othe
Michelle Caisse wrote:
> I've attached a patch that allows the generation of code coverage
> statistics. To test it, apply the patch, then:
>
> autoconf
> ./configure --enable-coverage
> make
> make check (or execute any other application against the database to see
> the coverage of that app)
Peter Eisentraut wrote:
Michelle Caisse wrote:
gcov gets confused when source files are generated. I eliminated
src/backend/bootstrap and ../parser from coverage analysis to avoid
errors of this type.
The problem with those files is that the source file contains lines like this:
#line 1042 "y
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We're pretty much assuming bison anyway, no? It's been years since
>> I heard of anyone successfully building the backend grammar with plain
>> yacc.
> In my recollection, you were the last holdout on that with the
> occasional HP
Tom Lane wrote:
We're pretty much assuming bison anyway, no? It's been years since
I heard of anyone successfully building the backend grammar with plain
yacc.
In my recollection, you were the last holdout on that with the
occasional HP-UX yacc test. But I seem to recall that that combinatio
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Korry Douglas wrote:
>> Why not use the %output directive in the grammar file instead; that way
>> you don't need to add any special flags to the Makefile.
> I think only bison supports that directive.
We're pretty much assuming bison anyway, no? I
Korry Douglas wrote:
1) Use bison's -o option to put the output file in the right place
directly,
if we are dealing with bison (and don't bother to support code coverage
analysis with other yaccs), or
2) Run a pattern replacement across the grammar output files as their are
renamed.
Why not u
The problem with those files is that the source file contains lines
like this:
#line 1042 "y.tab.c"
but that source file does not exist, as it is renamed to gram.c.
We could fix that in one of two ways:
1) Use bison's -o option to put the output file in the right place
directly,
if we are
Gregory Stark wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
The reason for that problem is that the shared object needs to be linked
with -fprofile-arcs -ftest-coverage. (One of these causes -lgcov to be
linked, which includes the missing symbol.) This is not done because the
shared o
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The reason for that problem is that the shared object needs to be linked
> with -fprofile-arcs -ftest-coverage. (One of these causes -lgcov to be
> linked, which includes the missing symbol.) This is not done because the
> shared object link rule
Michelle Caisse wrote:
> Also, two tests fail with the following diff when the build is
> configured with --enable-coverage.
>RETURNS trigger
>AS
> '/home/michelle/trunkClean/pgsql/src/test/regress/../../../contrib/spi/refi
>nt.so' LANGUAGE C;
> + ERROR: could not load library
> "/
Michelle Caisse wrote:
> gcov gets confused when source files are generated. I eliminated
> src/backend/bootstrap and ../parser from coverage analysis to avoid
> errors of this type.
The problem with those files is that the source file contains lines like this:
#line 1042 "y.tab.c"
but that sour
I've attached a patch that allows the generation of code coverage
statistics. To test it, apply the patch, then:
autoconf
./configure --enable-coverage
make
make check (or execute any other application against the database to see
the coverage of that app)
make coverage
make coverage_out
You w
16 matches
Mail list logo
