Re: [HACKERS] "make check" with non-GNU make

[Tom Lane]

Thomas Munro  writes:
> On Wed, Aug 9, 2017 at 3:44 PM, Tom Lane  wrote:
>> Hmm, looking into Makefile.global.in, that step seems to be conditional on
>> MAKELEVEL:

> Ah, right.  That coding is recommended in the GNU make manual to
> distinguish from explicit invocation and recursive invocation.
> FreeBSD make also seems to set MAKELEVEL.

Oh, that would do it.

> Doing this fixes the
> problem for me, though it feels a bit sneaky:

> -  $${GMAKE} $@ ; \
> +  MAKELEVEL= $${GMAKE} $@ ; \

Seems like a reasonable fix to me.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] "make check" with non-GNU make

[Thomas Munro]

On Wed, Aug 9, 2017 at 3:44 PM, Tom Lane  wrote:
> Thomas Munro  writes:
>> 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.
>
> Hmm, looking into Makefile.global.in, that step seems to be conditional on
> MAKELEVEL:
>
> temp-install:
> ifndef NO_TEMP_INSTALL
> ifneq ($(abs_top_builddir),)
> ifeq ($(MAKELEVEL),0)

Ah, right.  That coding is recommended in the GNU make manual to
distinguish from explicit invocation and recursive invocation.
FreeBSD make also seems to set MAKELEVEL.  Doing this fixes the
problem for me, though it feels a bit sneaky:

diff --git a/Makefile b/Makefile
index 72e9c83733..399e69540f 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ all check install installdirs installcheck
installcheck-parallel uninstall clean
\
 if [ x"$${GMAKE+set}" = xset ]; then \
   echo "Using GNU make found at $${GMAKE}"; \
-  $${GMAKE} $@ ; \
+  MAKELEVEL= $${GMAKE} $@ ; \
 else \
   echo "You must use GNU make to build PostgreSQL." ; \
   false; \

-- 
Thomas Munro
http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] "make check" with non-GNU make

[Tom Lane]

Thomas Munro  writes:
> 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.

Hmm, looking into Makefile.global.in, that step seems to be conditional on
MAKELEVEL:

temp-install:
ifndef NO_TEMP_INSTALL
ifneq ($(abs_top_builddir),)
ifeq ($(MAKELEVEL),0)
rm -rf '$(abs_top_builddir)'/tmp_install
$(MKDIR_P) '$(abs_top_builddir)'/tmp_install/log
$(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install 
install >'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
endif
$(if $(EXTRA_INSTALL),for extra in $(EXTRA_INSTALL); do $(MAKE) -C 
'$(top_builddir)'/$$extra DESTDIR='$(abs_top_builddir)'/tmp_install install 
>>'$(abs_top_builddir)'/tmp_install/log/install.log || exit; done)
endif
endif

I'm not real clear on how make invoking gmake would end up affecting
gmake's initial value of MAKELEVEL, but I bet the problem is somewhere
around there.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] "make check" with non-GNU make

[Thomas Munro]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers