> Yes. obviously. Stupid, errr, fingers.
This time round it really was fatfingering the wrong key after having
been climbing for 4h. Really.
Trivially updated patch attached.
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
>From 52fad5c7e645b514cdf23feddf08a3cd690363be Mon Sep 17 00:00:00 2001
From: Andres Freund <and...@anarazel.de>
Date: Thu, 29 Nov 2012 14:49:42 +0100
Subject: [PATCH] Unset MAKEFLAGS in pg_regress.c to hide the knowledge that
its invoked by make from submakes
Make stores some flags in the MAKEFLAGS variable to pass arguments to its own
children. If we are invoked by make that makes the make invoked by us think
it's part of the parallel make invoking us and tries to communicate with the
toplevel make. Which fails.
---
src/test/regress/pg_regress.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index 5a656f2..842eba1 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -783,6 +783,18 @@ initialize_environment(void)
}
/*
+ * make stores some flags in the MAKEFLAGS variable to pass arguments
+ * to its own children. If we are invoked by make that makes the make
+ * invoked by us think its part of the parallel make invoking us and
+ * tries to communicate with the toplevel make. Which fails.
+ *
+ * Unset the variable to protect against such problems. We also reset
+ * MAKELEVEL to be certain the child doesn't notice the make above us.
+ */
+ unsetenv("MAKEFLAGS");
+ unsetenv("MAKELEVEL");
+
+ /*
* Adjust path variables to point into the temp-install tree
*/
tmp = malloc(strlen(temp_install) + 32 + strlen(bindir));
--
1.7.12.289.g0ce9864.dirty
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
