Обсуждение: BUG #15407: [minor] build depends on $MAKELEVEL being 0 at topMakefile

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