<div dir="ltr">We have that already. <a href="https://releases.llvm.org/6.0.0/tools/clang/docs/UsersManual.html#configuration-files">https://releases.llvm.org/6.0.0/tools/clang/docs/UsersManual.html#configuration-files</a><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 27, 2020 at 5:15 PM Fangrui Song via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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 2020-02-26, Reid Kleckner via llvm-dev wrote:<br>
>I think "legacy" is the answer to most of your questions.<br>
><br>
>1. I think clang still uses ld by default, so clang-cl is similar. Besides,<br>
>every build system we encountered migrating from MSVC calls `link`<br>
>directly, and needed to be updated to call `lld-link`.<br>
><br>
>2. I think we should probably configure lld to find the clang resource<br>
>directory. At the very least, clang-cl -fuse-ld=lld should add it.<br>
><br>
>3. I think this is because there is no clang spelling for the /MD & /MT<br>
>flags, so we have to pick some CRT so that hello world links. You can work<br>
>around it with -nodefaultlib and passing your own.<br>
><br>
>4. That's true, but that's been the case for every build system we've<br>
>encountered.<br>
><br>
>So, I think there is room for improvement and better defaults.<br>
><br>
>Most options in clang are controlled by flags, not configure-time cmake<br>
>options. From the clang developer perspective, this is good, clang is<br>
>always a cross compiler and can do anything anywhere at runtime. But from a<br>
>user or packager perspective, this is often painful. Users often write<br>
>compiler wrapper scripts to fill in their preferred default options:<br>
>default target, default include paths, default library paths, etc.<br>
><br>
>On Sun, Feb 23, 2020 at 12:37 PM Максим Власов via llvm-dev <<br>
><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
>> I'm getting trouble using clang with compiled libc++ on MSVC.<br>
>> 1. why clang chooses `link` over `lld-link` by default? I don't really<br>
>> wish to write `-fuse-ld=lld-link` every single time I build something.<br>
>> 2. why `lld-link` doesn't search inside default `lib` directory? I need to<br>
>> manually show him where it is although I put that binary in `<LLVM<br>
>> root>\lib\`<br>
>> 3. why clang invokes linker with `-defaultlib:libcmt`? I mean libc++ build<br>
>> guide under MSVC produces -MD version of either `libc++.lib` or `c++.lib`<br>
>> 4. Since (3), it's not possible to build anything without splitting<br>
>> compiler and linker calls - `clang` by default produces -MT versions of<br>
>> objects and linker fails to compose it with -MD library. No, `-dynamic`<br>
>> flag does not help either.<br>
>> Any fixes to these? Can I config clang somehow except `--config` option?<br>
<br>
May I rephrase the question as asking about the feasibility of GCC<br>
-specs= ?<br>
<br>
<a href="https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html</a><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>
</blockquote></div>