Re: make coverage-html on OS X

On 10/29/16 4:31 PM, Jim Nasby wrote:
> tl;dr: It's critical that you actually do a make install, or at least it 
> is if you've set --prefix with configure. If you don't, then even if you 
> do make check you'le going to get the *installed* libpq, and not the 
> *built* libpq.

I was not able to reproduce this.  I suspect that this would happen if
you don't disable System Integrity Protection, because if SIP is on,
then the environment variable DYLD_LIBRARY_PATH is disabled, and a
regression test run would be prone to use a mix of source tree and
install tree components.  Often, this is not a problem, but if your
source tree is built with different options than the previous install,
then it could make a mess.  Building with coverage instrumentation is
obviously one case where the build options are quite different.

> Also, looks like there's a race between the .info and .c.gcov targets 
> with parallel make; I'm wondering if there's a way to fix that by not 
> allowing parallelism in each directory...? (Presumably the issue is the 
> rm *.gcov). It'd be nice to fix this because -j speeds up coverage-html 
> a lot, even with just 2 cores.

I was not able to reproduce this.  The make rules look reasonable to me
for parallelism.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services