Re: Andres Freund
> That's due to MAKELEVEL:
>
> submake-generated-headers:
> ifndef NO_GENERATED_HEADERS
> ifeq ($(MAKELEVEL),0)
> $(MAKE) -C $(top_builddir)/src/backend generated-headers
> endif
> endif
>
> So the distcheck target needs to reset MAKELEVEL=0 - unless somebody has a
> better idea?
Fwiw, I've had that problem as well in the Debian packages where
debian/rules is already a Makefile and calling $(MAKE) from there
trips up that logic. The workaround I used is:
override_dh_auto_build-arch:
# set MAKELEVEL to 0 to force building submake-generated-headers in
src/Makefile.global(.in)
MAKELEVEL=0 $(MAKE) -C build/src all
...
override_dh_auto_test-arch:
ifeq (, $(findstring nocheck, $(DEB_BUILD_OPTIONS)))
# when tests fail, print newest log files
# initdb doesn't like LANG and LC_ALL to contradict, unset LANG and
LC_CTYPE here
# temp-install wants to be invoked from a top-level make, unset
MAKELEVEL here
# tell pg_upgrade to create its sockets in /tmp to avoid too long paths
unset LANG LC_CTYPE MAKELEVEL; ulimit -c unlimited; \
if ! make -C build check-world \
$(TEMP_CONFIG) \
PGSOCKETDIR="/tmp" \
PG_TEST_EXTRA='ssl' \
PROVE_FLAGS="--verbose"; \
...
(Just mentioning this, not asking it to be changed.)
Re: Tom Lane
> Andres Freund <and...@anarazel.de> writes:
> > First thing I noticed that 'make dist' doesn't work in a vpath, failing in a
> > somewhat obscure way (likely because in a vpath build the the copy from the
> > source dir doesn't include GNUMakefile). Do we expect it to work?
>
> Don't see how it could possibly be useful in a vpath, because you'd have
> the real source files and the generated files in different trees.
I don't think "make dist" is generally expected to work in vpath
builds, that's probably one indirection layer too much. (The "make
distcheck" rule generated by automake tests vpath builds, though.)
Christoph
