diff options
author | Boris Kolpackov <boris@codesynthesis.com> | 2021-04-26 10:21:44 +0200 |
---|---|---|
committer | Boris Kolpackov <boris@codesynthesis.com> | 2021-04-26 10:21:44 +0200 |
commit | d55690a09ccc86b6ec285c9af2ab4f1921e84baf (patch) | |
tree | 537e3d6a70c82d3ca6f75e51c387b32ab64fb47d | |
parent | 7a96e3b0a4bb573bb26ca8ff93b97900bdb486b3 (diff) |
Detect and diagnose presence of certain GCC environment variables
Their presence is incompatible with what we are doing.
-rw-r--r-- | libbuild2/cc/guess.cxx | 9 | ||||
-rw-r--r-- | libbuild2/config/utility.hxx | 13 |
2 files changed, 14 insertions, 8 deletions
diff --git a/libbuild2/cc/guess.cxx b/libbuild2/cc/guess.cxx index ff96466..09e14fa 100644 --- a/libbuild2/cc/guess.cxx +++ b/libbuild2/cc/guess.cxx @@ -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. // // DEPENDENCIES_OUTPUT // SUNPRO_DEPENDENCIES @@ -2028,6 +2029,12 @@ namespace build2 // Environment. // + 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); switch (xl) { diff --git a/libbuild2/config/utility.hxx b/libbuild2/config/utility.hxx index 4673d0c..cec4bc3 100644 --- a/libbuild2/config/utility.hxx +++ b/libbuild2/config/utility.hxx @@ -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(). // |