llvm dev - Feb 2020 - Change default config of clang on Windows

I'm getting trouble using clang with compiled libc++ on MSVC.
1. why clang chooses `link` over `lld-link` by default? I don't really wish
to write `-fuse-ld=lld-link` every single time I build something.
2. why `lld-link` doesn't search inside default `lib` directory? I need to
manually show him where it is although I put that binary in `<LLVM
root>\lib\`
3. why clang invokes linker with `-defaultlib:libcmt`? I mean libc++ build
guide under MSVC produces -MD version of either `libc++.lib` or `c++.lib`
4. Since (3), it's not possible to build anything without splitting
compiler and linker calls - `clang` by default produces -MT versions of
objects and linker fails to compose it with -MD library. No, `-dynamic`
flag does not help either.
Any fixes to these? Can I config clang somehow except `--config` option?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200223/d8682eaa/attachment.html>

I think "legacy" is the answer to most of your questions.

1. I think clang still uses ld by default, so clang-cl is similar. Besides,
every build system we encountered migrating from MSVC calls `link`
directly, and needed to be updated to call `lld-link`.

2. I think we should probably configure lld to find the clang resource
directory. At the very least, clang-cl -fuse-ld=lld should add it.

3. I think this is because there is no clang spelling for the /MD & /MT
flags, so we have to pick some CRT so that hello world links. You can work
around it with -nodefaultlib and passing your own.

4. That's true, but that's been the case for every build system
we've
encountered.

So, I think there is room for improvement and better defaults.

Most options in clang are controlled by flags, not configure-time cmake
options. From the clang developer perspective, this is good, clang is
always a cross compiler and can do anything anywhere at runtime. But from a
user or packager perspective, this is often painful. Users often write
compiler wrapper scripts to fill in their preferred default options:
default target, default include paths, default library paths, etc.

On Sun, Feb 23, 2020 at 12:37 PM Максим Власов via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I'm getting trouble using clang with compiled libc++ on MSVC.
> 1. why clang chooses `link` over `lld-link` by default? I don't really
> wish to write `-fuse-ld=lld-link` every single time I build something.
> 2. why `lld-link` doesn't search inside default `lib` directory? I need
to
> manually show him where it is although I put that binary in `<LLVM
> root>\lib\`
> 3. why clang invokes linker with `-defaultlib:libcmt`? I mean libc++ build
> guide under MSVC produces -MD version of either `libc++.lib` or `c++.lib`
> 4. Since (3), it's not possible to build anything without splitting
> compiler and linker calls - `clang` by default produces -MT versions of
> objects and linker fails to compose it with -MD library. No, `-dynamic`
> flag does not help either.
> Any fixes to these? Can I config clang somehow except `--config` option?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200226/1446a23a/attachment.html>

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

https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html