[cfe-dev] [RFC] Changing tool search path priority

[David Spickett via cfe-dev]

Hi all,

I have a patch up for review that changes how external tools like gcc are
found [0]. Short version, more specific names on the user's PATH should be
found before less specific names that are in the clang install dir.

This was raised in a bug report [1] and I'll use that to describe the
current behaviour.

$ clang --target=aarch64-none-elf <...>

Clang looks for a GCC to use. With one of these possible names:
"aarch64-elf-none-gcc", "gcc", ""x86_64-unknown-linux-gnu-gcc" (which is
the default triple in this example)
We look for each name in the installed dir first, so if clang is in
/usr/bin we likely find /usr/bin/gcc. This isn't going to work for cross
compiling.

As in the bug, the user might expect clang to find an aarch64-elf-none-gcc
on their PATH if there is one. So my change switches things so that we look
for each name in the install dir (the "program path") and then the PATH. So
in this case we would search for aarch64-none-elf-gcc in the install dir
and on the PATH, before falling back to look for "gcc", and so on.

That makes sense for this situation but this code is quite generic so I
wanted to check if it's going to work for others. No existing tests were
broken by my patch, but I think that's probably just a lack of coverage on
this piece of code.

A couple of things to note:
* -B paths are not changed by my patch, they still follow the old behaviour.
* You can work around this quite easily with -ccc-gcc-name or -B

Looking for feedback from anyone who is involved in toolchain packaging or
has been in this area recently. Is this an improvement overall and will it
break existing usage?

Thanks,
David Spickett.

[0] https://reviews.llvm.org/D79842
[1] https://bugs.llvm.org/show_bug.cgi?id=45693
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200514/a8689f55/attachment.html>