Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make configure respect (and save) values for
CC
, CXX
, CFLAGS
, etc.
I mostly tried to remain backwards compatible with old invocations of the `configure` script; if you do not want to use `CC` et al., you should not have to; you can keep using `--enable-clang` and/or `--enable-ccache`. The overall intention is to capture the following precedences for guessing the C compiler: 1. Value of `CC` at make invocation time. 2. Value of `CC` at configure invocation time. 3. Compiler inferred at configure invocation time (`gcc` or `clang`). The strategy is to check (at `configure` time) if each of the environment variables is set, and if so, save its value in a corresponding `CFG_` variable (e.g. `CFG_CC`). Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we use the `CFG_CC` setting as `CC`. Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS` values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings. (This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various parts of the mk files.) Fix #13805. ---- Note that if you try to set the compiler to clang via the `CC` and `CXX` environment variables, you will probably need to also set `CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured properly. ---- Introduce CFG_USING_CLANG, which is distinguished from CFG_ENABLE_CLANG because the former represents "we think we're using clang, choose appropriate warning-control options" while the latter represents "we asked configure (or the host required) that we attempt to use clang, so check that we have an appropriate version of clang." The main reason I added this is that I wanted to allow the user to choose clang via setting the `CC` environment variable, but I did not want that method of selection to get confused with the user passing the `--enable-clang` option. ---- A digression: The `configure` script does not infer the compiler setting if `CC` is set; but if `--enable-clang` was passed, then it *does* still attempt to validate that the clang version is compatible. Supporting this required revising `CLANG_VERSION` check to be robust in face of user-provided `CC` value. In particular, on Travis, the `CC` is set to `gcc` and so the natural thing to do is to attempt to use `gcc` as the compiler, but Travis is also passing `--enable-clang` to configure. So, what is the right answer in the face of these contradictory requests? One approach would be to have `--enable-clang` supersede the setting for `CC` (and instead just call whatever we inferred for `CFG_CLANG`). That sounds maximally inflexible to me (pnkfelix): a developer requesting a `CC` value probably wants it respected, and should be able to set it to something else; it is harder for that developer to hack our configure script to change its inferred path to clang. A second approach would be to blindly use the `CC` value but keep going through the clang version check when `--enable-clang` is turned on. But on Travis (a Linux host), the `gcc` invocation won't print a clang version, so we would not get past the CLANG_VERSION check in that context. A third approach would be to never run the CLANG_VERSION check if `CC` is explicitly set. That is not a terrible idea; but if the user uses `CC` to pass in a path to some other version of clang that they want to test, probably should still send that through the `CLANG_VERSION` check. So in the end I (pnkfelix) took a fourth approach: do the CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string ending with `clang`. This way setting `CC` to things like `path/to/clang` or `ccache clang` will still go through the CLANG_VERSION check, while setting `CC` to `gcc` or some unknown compiler will skip the CLANG_VERSION check (regardless of whether the user passed --enable-clang to `configure`). ---- Drive-by fixes: * The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in its invocation, but that does not play nicely with someone who sets `$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret that whole string as a command. (On the other hand, a path with spaces might need the quoted invocation. Not sure which one of these corner use-cases is more important to support.) * Fix chk_cc error message to point user at `gcc` not `cc`.
- Loading branch information
ae67b74
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
saw approval from alexcrichton
at pnkfelix@ae67b74
ae67b74
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
merging pnkfelix/rust/fsk-fix-13805 = ae67b74 into auto
ae67b74
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pnkfelix/rust/fsk-fix-13805 = ae67b74 merged ok, testing candidate = f30382d
ae67b74
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all tests pass:
success: http://buildbot.rust-lang.org/builders/auto-mac-32-opt/builds/5864
success: http://buildbot.rust-lang.org/builders/auto-mac-64-opt/builds/5862
success: http://buildbot.rust-lang.org/builders/auto-mac-64-nopt-c/builds/4958
success: http://buildbot.rust-lang.org/builders/auto-mac-64-nopt-t/builds/4966
success: http://buildbot.rust-lang.org/builders/auto-linux-32-opt/builds/5961
success: http://buildbot.rust-lang.org/builders/auto-linux-32-nopt-c/builds/5050
success: http://buildbot.rust-lang.org/builders/auto-linux-32-nopt-t/builds/5058
success: http://buildbot.rust-lang.org/builders/auto-linux-64-opt/builds/5964
success: http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-c/builds/5049
success: http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-t/builds/5055
success: http://buildbot.rust-lang.org/builders/auto-linux-64-x-android/builds/5117
success: http://buildbot.rust-lang.org/builders/auto-linux-64-x-android-t/builds/2850
success: http://buildbot.rust-lang.org/builders/auto-win-32-opt/builds/5957
success: http://buildbot.rust-lang.org/builders/auto-win-32-nopt-c/builds/5053
success: http://buildbot.rust-lang.org/builders/auto-win-32-nopt-t/builds/5068
ae67b74
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fast-forwarding master to auto = f30382d