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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
