<div dir="ltr">Is there any more feedback on this from anybody? The conclusion of it is blocking progress on a patch series.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 7 May 2021 at 08:22, James Henderson <<a href="mailto:jh7370.2008@my.bristol.ac.uk">jh7370.2008@my.bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 6 May 2021 at 17:56, Fangrui Song <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2021-05-06, James Henderson via llvm-dev wrote:<br>
>Hi all,<br>
><br>
>Summary: can we stop allowing clang/lld to be picked up from the PATH<br>
>environment when running testing?<br>
><br>
>Details:<br>
><br>
>As part of my work on a cross-project testsuite (see<br>
><a href="https://reviews.llvm.org/D95339" rel="noreferrer" target="_blank">https://reviews.llvm.org/D95339</a> and other related patches), I noticed that<br>
>where lit has been configured using `use_clang()` or `use_lld()` the<br>
>respective tools will be selected from the system PATH, if they aren't<br>
>found in the build directory. If users are running check-* to run the<br>
>relevant tests, this isn't an issue, as the tools will be built (and<br>
>therefore used in preference).<br>
><br>
>I personally, and I'm sure many others, routinely don't use these check-*<br>
>targets, preferring to manually build and run the subset of tests that have<br>
>the potential to be impacted by my change. Potentially this leaves room for<br>
>human error (e.g. a misconfigured build bot or simply a user error when<br>
>checking things) to not build clang (or lld) in a clean environment, and as<br>
>such, the "wrong" tool might be used, causing spurious tests failures (or<br>
>worse, spurious passes).<br>
><br>
>An environment variable ('CLANG') can be specified to specify the clang<br>
>executable to use, in preference to a built one or one on the PATH. I plan<br>
>to make a similar change for LLD soon too. As such, do we need the "use the<br>
>PATH version" behaviour anymore? Dropping it will allow simplifying code<br>
>and reduce room for human error.<br>
<br>
Is the plan to allow running the testsuite with Clang/LLD built from a<br>
different commit?<br></blockquote><div><br></div><div>In the case of the debuginfo-tests, a request was made in <a href="https://reviews.llvm.org/D95339" target="_blank">https://reviews.llvm.org/D95339</a> that an installed LLDB could be used for some basic backwards compatibility testing. The code path that finds LLDB is the same one as used for the CLANG variable discussed in my email, so the same mechanism should be used for them (and LLD too, which uses the same mechanism). I don't have any specific use-case, beyond that, but it would seem silly to have one customisation point for one of these tools, but not for the others in the set.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If every executable needs an environment variable, I worry that there may be<br>
too much customization.<br></blockquote><div><br></div><div>The only tools impacted by this are clang (including clang++ and clang-cl), LLDB (in the debuginfo-tests only), and LLD (specifically its 4 variants ld.lld/ld64.lld/lld-link/wasm-ld). These are the only places that call use_llvm_tool currently (either via use_clang/use_lld or directly). The existing mechanism for this relies on the variable pointing directly at the executable. As such, we need one variable per executable (a maximum of 8 possible variables should a user want to specify all of them). I could obviously change this mechanism, to specify a directory, but this may not always be useful, if a user has versions of a tool without the default name (e.g. with release number suffixes etc).</div><div><br></div><div>Note that the only way to use the PATH versions is if someone hasn't built the executables in question, as the build directory version is picked above the PATH version anyway.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>Thanks,<br>
><br>
>James<br>
<br>
>_______________________________________________<br>
>LLVM Developers mailing list<br>
><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote></div></div>
</blockquote></div>