2 files changed, 14 insertions, 8 deletions
diff --git a/libbuild2/cc/guess.cxx b/libbuild2/cc/guess.cxx
index ff96466..09e14fa 100644
@@ -1815,7 +1815,8 @@ namespace build2
// See "Environment Variables Affecting GCC".
- // @@ TODO: It feels like we should unset the following variables:
+ // Note that we also check below that the following variables are not set
+ // since they would interfere with what we are doing.
@@ -2028,6 +2029,12 @@ namespace build2
+ if (getenv ("DEPENDENCIES_OUTPUT"))
+ fail << "GCC DEPENDENCIES_OUTPUT environment variable is set";
+ if (getenv ("SUNPRO_DEPENDENCIES"))
+ fail << "GCC SUNPRO_DEPENDENCIES environment variable is set";
const char* const* c_env (nullptr);
diff --git a/libbuild2/config/utility.hxx b/libbuild2/config/utility.hxx
index 4673d0c..cec4bc3 100644
@@ -104,13 +104,12 @@ namespace build2
// 4. Finally, there could be environment variables that are incompatible
// with what we are doing (e.g., they change the mode of operation or
- // some such; see GCC's DEPENDENCIES_OUTPUT for example). While they
- // can be cleared for each invocation, this is burdensome and it is
- // often easier to just unset them for the entire build system process
- // if we can be reasonable sure that there can be no plausible use for
- // this variable (e.g., by another module or by the buildfile
- // directly). The module's load() function is a natural place to do
- // that.
+ // some such; see GCC's DEPENDENCIES_OUTPUT for example). The two ways
+ // to deal with this is either clear them for each invocation or, if
+ // that's too burdensome and there is no good reason to have the build
+ // system invoked with such variables, detect their presence and fail.
+ // Note that unsetting them for the entire build system process is not
+ // an option since that would be racy.
// See also build2::hash_environment().