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