Prefer /usr/bin/clang as default CC on darwin
#10823
Conversation
d4fd541 to
c476abf
Compare
| [darwin*], [ | ||
| # /usr/bin/clang is always available as long as Command Line Tools or Xcode is installed. | ||
| # Prefer absolute path to avoid PATH lookup, which may lead to unaligned tool selection. | ||
| rb_darwin_default_CC=/usr/bin/clang | ||
| AC_MSG_CHECKING([for darwin default CC $rb_darwin_default_CC]) | ||
| AS_IF([test -z "$CC" -a -x "$rb_darwin_default_CC"], | ||
| [ | ||
| AC_MSG_RESULT([yes]) | ||
| CC=$rb_darwin_default_CC | ||
| ], | ||
| [ | ||
| AC_MSG_RESULT([no]) | ||
| # Fall back to PATH lookup just in case the /usr/bin/clang is not | ||
| # available for some reason. | ||
| AC_CHECK_TOOLS([CC], [clang cc gcc c99]) | ||
| ] | ||
| ) |
There was a problem hiding this comment.
What about expand rb_CC absolute path, only if the found CC is Xcode?
AS_IF([$rb_CC -E -dM -xc - < /dev/null | grep -F __apple_build_version__ > /dev/null],
[llvm_prefix= rb_CC=`command -v $rb_CC`], [llvm_prefix=llvm-])
There was a problem hiding this comment.
What we are trying to solve is unaligned toolset selection in the situation where PATH contains mixed toolchains (e.g. LLVM from Homebrew, Conda toolchain?, and Xcode).
e.g.
$ ls /path/to/conda/bin
clang # but no nm
$ ls /usr/bin
clang nm ...
$ export PATH=/path/to/conda:/usr/binIf we continue looking up CC from PATH and align toolset only when CC comes from Xcode, the problem won't be mitigated for the above situation.
That's why I prefer fixed /usr/bin/clang as the default decision.
There was a problem hiding this comment.
Not disagreeing with you as such, but it should be pointed out that at the least on Linux, the default assumption is that the entries in $PATH coming first, have higher precedence. So, for instance, if a user would have a PATH that first has /opt/bin/, and /usr/bin/ as second entry, then /opt/bin/ should be searched first. This will probably happen only very, very rarely, so it does not invalidate your statement, but I wanted to mention it in regards to (possible) user's expectations.
If we continue looking up CC from PATH and align toolset only when CC comes from Xcode, the problem won't be mitigated for the above situation.
Right, but it should also pointed out that this appears to be an incorrect assumption by conda then, if it assumes that the bin/ it searches for must be in the same directory (e. g. assuming /usr/bin/). My clang binary, for instance, is under /home/Programs/Llvm/18.1.2/bin/, for instance. (I follow a symlink-version approach similar to GoboLinux, but I also only use /usr/bin/ and just update the current symlink in use, for all programs on my linux machine, just as info; obviously darwin follows another scheme.)
There was a problem hiding this comment.
I think we should abort in that case, if not [test -x "${rb_prog}"], rather than searching from $PATH.
There was a problem hiding this comment.
It makes sense to me. It sounds well consistent behavior.
There was a problem hiding this comment.
I think rb_darwin_default_CC is not needed anymore.
There was a problem hiding this comment.
Sorry, do you mean we should find CC from PATH instead of having the default value?
There was a problem hiding this comment.
Yes, only for Xcode clang, as commented above.
c476abf to
a2fcbfd
Compare
a2fcbfd to
d4f4e11
Compare
`/usr/bin/clang` is always available as long as Command Line Tools or Xcode is installed. Prefer the absolute path to avoid PATH lookup, which may lead to unaligned toolset selection. This change makes toolset selection more robust by: 1. Use `/usr/bin/clang` as default CC on darwin. 2. Prefer other tools next to `CC` if selected CC is absolute and the tool is not explicitly specified.
d4f4e11 to
51b7b2f
Compare
/usr/bin/clangis always available as long as Command Line Tools or Xcode is installed. Prefer the absolute path to avoid PATH lookup, which may lead to unaligned toolset selection.This change makes toolset selection more robust by:
/usr/bin/clangas default CC on darwin.CCif selected CC is absolute and the tool is not explicitly specified.