mgorny added a comment. In D134337#3813779 <https://reviews.llvm.org/D134337#3813779>, @sepavloff wrote:
> First clang tries to find `x86_64-pc-linux-gnu-clang.cfg`. Just tool name > with added suffix `cfg`. No target override, no attempt to split tool name > into components. It provides possibility to have a separate configuration for > any tool. The existing mechanism does not search for such file, so > compatibility cannot be broken. This variant makes it possible to use > configuration file even if tool name is arbitrary and does not follow usual > pattern. That's incorrect. The existing algorithm uses precisely this file if that's how clang is named: $ ./bin/x86_64-pc-linux-gnu-clang --version clang version 16.0.0 (g...@github.com:llvm/llvm-project.git 17779984ca4441657071ea5abe6ef2bb32306dce) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /home/mgorny/git/llvm-project/build/./bin Configuration file: /tmp/clang-config/x86_64-pc-linux-gnu-clang.cfg Also note that it performs the arch substitution on this path: $ ./bin/x86_64-pc-linux-gnu-clang --version -m32 clang version 16.0.0 (g...@github.com:llvm/llvm-project.git 17779984ca4441657071ea5abe6ef2bb32306dce) Target: i386-pc-linux-gnu Thread model: posix InstalledDir: /home/mgorny/git/llvm-project/build/./bin Configuration file: /tmp/clang-config/i386-pc-linux-gnu-clang.cfg So your proposal breaks backwards compatibility. > If `x86_64-pc-linux-gnu-clang.cfg` is found, it is loaded as configuration > file and that's all. Otherwise the middle components are dropped and only > target prefix and driver mode suffix are used for the search. It is similar > to the search made by existing implementation, the following files that are > looked for : > > - `i386-clang.cfg` > - `i386.cfg` > - `x86_64-clang.cfg` > - `x86_64.cfg` > > If the file found has form `target.cfg` or none of the files was found, clang > tries to load driver-mode configuration file. The files are the same as in > your algorithm: > > - `clang++.cfg` > - `clang.cfg` > > The driver-mode configuration is loaded prior to the target config, - as it > may contain default settings that target config may override. In the current > implementation such files are not, risk of breaking compatibility is minimal. > > What do you think about this variant? Does it fit your use case? Well, my immediate use case only needs per-driver mode configuration files, so it would work — presuming we're using the real driver mode and not the executable suffix. However, I definitely do see potential use cases for per-target configuration files — for example, providing target-specific paths instead of hardcoding them in the driver. Please note that architecture part alone is insufficient here — there are ABIs (such as n32 ABI on mips or x32 ABI on x86_64) that can only be distinguished by `-gnuabin32` or `-gnux32` suffix rather than the architecture part. This is also relevant to hardfloat/softfloat targets, and the larger part of the triple is definitely needed for cross-toolchains that may target different operating systems. Perhaps it would be easier if you described your use case to me — I presume you have one as author of the original patch. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134337/new/ https://reviews.llvm.org/D134337 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
