jroelofs wrote:
> In my use case, and probably in most use cases, the location where the link
> comes from is a plain folder, not a hierarchy specific to a toolchain.
I would have expected the opposite. Most non-windows clang toolchains that I
know of typically ship `clang` and `clang++` as symlinks to a single binary
named `clang-${version}`, all of which are located in the typical
bin-next-to-lib toolchain folder structure. Darwin toolchains are a _little_
weird, since we don't ship libc++ & co. in `bin/../{lib,include}`, and instead
those go in an "SDK" (much like a "sysroot" on other platforms).
As an aside, there is also driver mode selection logic that depends heavily on
the specific names of these symlinks, e.g. for C vs C++ mode, clang-cl mode,
and/or cross-compiling to a specific target when prefixed with the target
triple e.g. `arm-none-eabi-clang -> clang`.
Don't consider this an objection, but: for your use case, can you stick
symlinks in to preserve that toolchain folder structure relative to the
`~/tmp/clang++` symlink? i.e. make that `~/tmp/bin/clang++ ->
/Users/ilg/Library/xPacks/@xpack-dev-tools/clang/15.0.7-3.1/.content/bin/clang-15`
and add `~/tmp/lib ->
/Users/ilg/Library/xPacks/@xpack-dev-tools/clang/15.0.7-3.1/.content/lib` (and
same for `include`).
https://github.com/llvm/llvm-project/pull/70817
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
