On Tue, Jun 23, 2015 at 1:31 AM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
>> I tracked the dangerous -rf to come from Makefile.global and it's empty
>> string being due to abs_top_builddir not being define in my own Makefile.
>> But beside that, which I can probably fix, it doesn't sound correct
>> that a "check" rule insists in finding an "install" rule.
>
> Oops, this is a regression, and a dangerous one indeed. This is caused
> by dcae5fac.
>
> One fix is to use NO_TEMP_INSTALL=yes in Makefile.global in the
> context of PGXS, like in the patch attached, this variable needing to
> be set before Makefile.global is loaded. We could as well use directly
> PGXS in the section "Testing", but that does not sound appealing for
> Makefile.global's readability.

Gulp.  I certainly agree that emitting rm -rf /tmp_install is a scary
thing for a PostgreSQL Makefile to be doing.  Fortunately, people
aren't likely to have a directory under / by that name, and maybe not
permissions on it even if they did, but all the same it's not good.  I
propose trying to guard against that a bit more explicitly, as in the
attached.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index c583b44..081ed5d 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -304,12 +304,14 @@ check: temp-install
 .PHONY: temp-install
 temp-install:
 ifndef NO_TEMP_INSTALL
+ifneq ($(abs_top_builddir),)
 ifeq ($(MAKELEVEL),0)
 	rm -rf '$(abs_top_builddir)'/tmp_install
 	$(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install
 endif
 	$(if $(EXTRA_INSTALL),for extra in $(EXTRA_INSTALL); do $(MAKE) -C '$(top_builddir)'/$$extra DESTDIR='$(abs_top_builddir)'/tmp_install install || exit; done)
 endif
+endif
 
 PROVE = @PROVE@
 PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to