Re: Having problems generating a code coverage report

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: Having problems generating a code coverage report
Date: 2026-02-16 01:49:14
Message-ID: aZJ3mpqZ-jECaZ9r@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 14, 2026 at 09:04:44AM +0100, Stefan Kaltenbrunner wrote:
> While I certainly can try to locally hack around that further to get it
> build it feels wrong to post process/patch our own tree to get "official"
> coverage reporting...

Are you using a VPATH build? That was the only build option that was
causing me problems on Debian GID even with the tweaks proposed by
Andres in a .lcovrc. Non-vpath under configure and meson worked
unpatched. With vpath under configure, that worked but the
directories were in a weird state (contrib/ missing from the root
patch, $HOME included). meson was much slower than the two others.

I have also tried a few more experiments on Fedora 34 lately, that
points to even newer versions of all these tools. Things are even
more broken moving forward for meson, vpath and non-vpath. This is
testing things with an unpatched PG tree, just mentioning that it
does not seem to get better as time goes..
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2026-02-16 03:10:46 RE: BUG: Former primary node might stuck when started as a standby
Previous Message Michael Paquier 2026-02-16 01:15:08 Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable