[PATCH] D134337: [clang] [Driver] More flexible rules for loading default configs (WIP)

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

In D134337#3813798 <https://reviews.llvm.org/D134337#3813798>, @mgorny wrote:

> 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:

I was wrong, the target prefix reported by `ToolChain::getTargetAndModeFromProgramName` is everything but the driver component, so indeed the first file tried for configuration is `x86_64-pc-linux-gnu-clang.cfg`. So the new algorithm would try files tried by current implementation and risk of breaking compatibility would be minimized.

In D134337#3805368 <https://reviews.llvm.org/D134337#3805368>, @mgorny wrote:

> For target, it will try:
>
> 1. `i386.cfg` (effective triple)
> 2. `i386-pc-linux-gnu.cfg` ("fixed" prefix)
> 3. `x86_64-pc-linux-gnu.cfg` (orig. prefix)

Does it mean that `i386.cfg` would be tried before `i386-pc-linux-gnu.cfg`? It looks more natural to try specific variant first then generic. File `x86_64.cfg` is not used in this algorithm, what is the reason for this?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134337/new/

https://reviews.llvm.org/D134337