Andy Polyakov

I spy unjustified "but" :-) But on a serious note, the wording suggests that spotting Llvm is something that would be necessary, while it's by all means optional. Well, one...

> this isn't an issue about arbitrary installations of LLVM tools — LLVM tools are installed to `VC\Tools\Llvm` specifically when installed as a Visual Studio component At the same time...

>> At the same time if user has installed "arbitrary" LLVM toolkit and made arrangements to use specifically that, it would be inappropriate to override the choice. Would you agree?...

I don't follow. I asked if you would agree that overriding user choice would be inappropriate. And you didn't agree, i.e. you would find overriding user preferences appropriate. And doesn't...

Quoting my initial remark, "detect if there is clang-cl on the program search path (and check that it matches the target platform?) and only then attempt to see if it's...

Well, arguably suggested scenario is unlikely to be a common case, but I've added unique prefix based on absolute path for maintainers to consider :-)

> I'd remove the path grafting entirely now. Even for relative paths? The original idea was to be as conservative as possible. I mean **not** changing the way it currently...

> I've thought of "flattening" and reckoned that keeping traces of the directory structure could be helpful for trouble-shooting purposes. On the other hand, one can totally say that "flattening"...

Note for maintainers. There are three suggestions to consider, one per commit. First one attempts to graft subdirectories of absolute source files' paths to output directory. The second one prefixes...

> * should there be a "global" method that would trigger linking with spectre-mitigated libraries in case the user doesn't compile any C/C++? Just in case, my personal opinion is...