From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | "make check" with non-GNU make |
Date: | 2017-08-09 01:08:35 |
Message-ID: | CAEepm=1ueww35AXTkt1A3gyzZUqv5XCzh8RUNvJZAQAW=eOhVw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
Does anyone know why "make check" doesn't work on BSD systems if
tmp_install doesn't exist yet? It's no big deal, you just have to run
"gmake check", but Makefile is supposed to do that for you and it
works fine for every other target. No big deal, but it'd be nice to
unravel this mystery...
Specifically, if you run "make check" then it invokes
"/usr/local/bin/gmake check" for you, but it seem to skip the step
that builds tmp_install and so then pg_regress fails. If you run
"/usr/local/bin/gmake check" directly then it works, and then future
invocations of "make check" work after that until you next "make
clean" because tmp_install is already there. One thing I note is that
gmake knows that it's been invoked recursively by a make (in this case
an alien make), judging by the numbers that it prints in square
brackets, so I assume that some communication via environment
variables is causing this, but I can't explain it.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-08-09 01:32:19 | Re: Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b |
Previous Message | Amit Langote | 2017-08-09 00:31:17 | Re: dubious error message from partition.c |