Complement the configuration file search logic to use
default-<mode-suffix>.cfg or default.cfg if clang is called
via the executable without a prefix specifying target. This makes it
possible for vendors to supply a full set of configuration files
matching all installed executables.
Details
- Reviewers
rsmith sepavloff asymptotically MaskRay
Diff Detail
Event Timeline
A similar RFC for this was proposed here: https://discourse.llvm.org/t/rfc-adding-a-default-file-location-to-config-file-support/63606
As @sepavloff points out in the linked discussion, we probably need an option to disable loading default configuration files too, and we should use it in the test suite (via modifying the %clang substitutions, I guess), as otherwise someone enabling config file support is going to see random test failures.
On this topic, it would be great if we could pick up a per-target default config file too, if clang is invoked with clang -target <triple>. Currently this is done automatically if clang is invoked as <triple>-clang, but not with an explicit -target parameter.
So far my plan is to go for default-{ModeSuffix}.cfg instead (e.g. default-clang.cfg, default-clang++.cfg, etc.). If I'm not mistaken, this will trigger the existing fallback logic stripping mode suffix and trying default.cfg if suffixed config is not found. Also add tests ;-).
clang/docs/UsersManual.rst | ||
---|---|---|
911–912 | These single backsticks probably should be double backsticks. |
Thanks for taking over the patch!
I've CCed (in https://discourse.llvm.org/t/rfc-adding-a-default-file-location-to-config-file-support/63606/33) some folks who had strong opinions in the initial support patch.
(Cc @joerg manually whom I cannot find a discourse username for)
Changed the base config filename to default.cfg, and included looking up default-<mode-suffix>.cfg first. Added tests.
clang/docs/UsersManual.rst | ||
---|---|---|
911–912 | To be honest, I was wondering why it was done like that. |
As an example, we are currently installing the following set of executables + symlinks for clang in Gentoo on amd64 with full multilib:
lrwxrwxrwx 1 root root 8 Sep 17 12:31 /usr/lib/llvm/16/bin/clang -> clang-16 lrwxrwxrwx 1 root root 10 Sep 17 12:31 /usr/lib/llvm/16/bin/clang++ -> clang++-16 lrwxrwxrwx 1 root root 8 Sep 17 12:31 /usr/lib/llvm/16/bin/clang++-16 -> clang-16 -rwxr-xr-x 1 root root 170K Sep 17 12:31 /usr/lib/llvm/16/bin/clang-16 lrwxrwxrwx 1 root root 11 Sep 17 12:31 /usr/lib/llvm/16/bin/clang-cl -> clang-cl-16 lrwxrwxrwx 1 root root 8 Sep 17 12:31 /usr/lib/llvm/16/bin/clang-cl-16 -> clang-16 lrwxrwxrwx 1 root root 12 Sep 17 12:31 /usr/lib/llvm/16/bin/clang-cpp -> clang-cpp-16 lrwxrwxrwx 1 root root 8 Sep 17 12:31 /usr/lib/llvm/16/bin/clang-cpp-16 -> clang-16 lrwxrwxrwx 1 root root 26 Sep 17 12:31 /usr/lib/llvm/16/bin/i686-pc-linux-gnu-clang -> i686-pc-linux-gnu-clang-16 lrwxrwxrwx 1 root root 28 Sep 17 12:31 /usr/lib/llvm/16/bin/i686-pc-linux-gnu-clang++ -> i686-pc-linux-gnu-clang++-16 lrwxrwxrwx 1 root root 10 Sep 17 12:31 /usr/lib/llvm/16/bin/i686-pc-linux-gnu-clang++-16 -> clang++-16 lrwxrwxrwx 1 root root 8 Sep 17 12:31 /usr/lib/llvm/16/bin/i686-pc-linux-gnu-clang-16 -> clang-16 lrwxrwxrwx 1 root root 29 Sep 17 12:31 /usr/lib/llvm/16/bin/i686-pc-linux-gnu-clang-cl -> i686-pc-linux-gnu-clang-cl-16 lrwxrwxrwx 1 root root 11 Sep 17 12:31 /usr/lib/llvm/16/bin/i686-pc-linux-gnu-clang-cl-16 -> clang-cl-16 lrwxrwxrwx 1 root root 30 Sep 17 12:31 /usr/lib/llvm/16/bin/i686-pc-linux-gnu-clang-cpp -> i686-pc-linux-gnu-clang-cpp-16 lrwxrwxrwx 1 root root 12 Sep 17 12:31 /usr/lib/llvm/16/bin/i686-pc-linux-gnu-clang-cpp-16 -> clang-cpp-16 lrwxrwxrwx 1 root root 28 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnu-clang -> x86_64-pc-linux-gnu-clang-16 lrwxrwxrwx 1 root root 30 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnu-clang++ -> x86_64-pc-linux-gnu-clang++-16 lrwxrwxrwx 1 root root 10 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnu-clang++-16 -> clang++-16 lrwxrwxrwx 1 root root 8 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnu-clang-16 -> clang-16 lrwxrwxrwx 1 root root 31 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnu-clang-cl -> x86_64-pc-linux-gnu-clang-cl-16 lrwxrwxrwx 1 root root 11 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnu-clang-cl-16 -> clang-cl-16 lrwxrwxrwx 1 root root 32 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnu-clang-cpp -> x86_64-pc-linux-gnu-clang-cpp-16 lrwxrwxrwx 1 root root 12 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnu-clang-cpp-16 -> clang-cpp-16 lrwxrwxrwx 1 root root 31 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnux32-clang -> x86_64-pc-linux-gnux32-clang-16 lrwxrwxrwx 1 root root 33 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnux32-clang++ -> x86_64-pc-linux-gnux32-clang++-16 lrwxrwxrwx 1 root root 10 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnux32-clang++-16 -> clang++-16 lrwxrwxrwx 1 root root 8 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnux32-clang-16 -> clang-16 lrwxrwxrwx 1 root root 34 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnux32-clang-cl -> x86_64-pc-linux-gnux32-clang-cl-16 lrwxrwxrwx 1 root root 11 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnux32-clang-cl-16 -> clang-cl-16 lrwxrwxrwx 1 root root 35 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnux32-clang-cpp -> x86_64-pc-linux-gnux32-clang-cpp-16 lrwxrwxrwx 1 root root 12 Sep 17 12:31 /usr/lib/llvm/16/bin/x86_64-pc-linux-gnux32-clang-cpp-16 -> clang-cpp-16
…and we can cover all of them using four config files:
-rw-r--r-- 1 root root 0 Sep 17 13:30 default.cfg lrwxrwxrwx 1 root root 11 Sep 17 12:31 i686-pc-linux-gnu.cfg -> default.cfg lrwxrwxrwx 1 root root 11 Sep 17 12:31 x86_64-pc-linux-gnu.cfg -> default.cfg lrwxrwxrwx 1 root root 11 Sep 17 12:31 x86_64-pc-linux-gnux32.cfg -> default.cfg
Fix documentation formatting. While at it, fix a doc mistake that referenced x86_64-cl.cfg instead of the correct x86_64-clang-cl.cfg.
clang/docs/UsersManual.rst | ||
---|---|---|
915 | What about using default config based on driver mode (clang.cfg, gcc.cfg etc)? It looks like a more flexible solution, - different driver modes may need different default settings. Even if these setting are identical, the default config files may be links to one, say clang.cfg or just include that file with @file. |
clang/docs/UsersManual.rst | ||
---|---|---|
915 | It's actually described below — you can have default-clang.cfg, default-clang++.cfg, etc. Using this naming makes it possible to use the same logic for default as for prefixed execs. |
Not really, we don't strictly need per-target config files at the moment. There might be some use for them in the future but right now our most dire need is to be able to ensure that our config file is included in all invocations (except for explicit --no-default-config).
With this patch, this is handled by having files for all installed prefixes + default* for unprefixed executables.
I suppose an alternative option would be to do a major refactoring to support a wider range of naming variants with fallbacks. Would you prefer if I tried to do that?
This says armv7l.cfg...