BUG #15407: [minor] build depends on $MAKELEVEL being 0 at top Makefile
The following bug has been logged on the website:
Bug reference: 15407
Logged by: Torsten Lüttgert
Email address: st-postgresql@luettgert.de
PostgreSQL version: 11beta4
Operating system: CentOS 7
Description:
We build postgresql as part of a larger runtime environment, and if the
top-level make is invoked from an existing, other Makefile (i.e., with
$MAKELEVEL set), the build fails like this:
relpath.c:21:37: fatal error: catalog/pg_tablespace_d.h: No such file or
directory
#include "catalog/pg_tablespace_d.h"
The file is there:
# find -name pg_tablespace_d.h
./src/backend/catalog/pg_tablespace_d.h
Workaround for us was to use
MAKELEVEL=0 $(MAKE)
instead.
On Thu, Sep 27, 2018 at 08:31:47AM +0000, PG Bug reporting form wrote:
The file is there:
# find -name pg_tablespace_d.h
./src/backend/catalog/pg_tablespace_d.h
Wouldn't you need something like that actually? I added this rule when
compiling some of my stuff with v11, which does not invoke make from the
root tree to make sure that those headers are present:
make -C $(topdir)/src/backend generated-headers
--
Michael
=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
We build postgresql as part of a larger runtime environment, and if the
top-level make is invoked from an existing, other Makefile (i.e., with
$MAKELEVEL set), the build fails like this:
...
Workaround for us was to use
MAKELEVEL=0 $(MAKE)
instead.
Yeah, this is now documented, near the bottom of the "2. Build" step at
https://www.postgresql.org/docs/11/static/install-procedure.html
It should be harmless to do that for pre-11 versions too.
regards, tom lane