Changed the default C compiler used to build nim from gcc to clang

[ghost]

Currently, Nim and its surrounding tools are built with gcc, but I would like to see this changed to building with clang.
On macOS/Linux, even gcc does not cause serious problems, but on Windows, the dependency on MinGW is a problem.

From my experience, it seems that products built with MinGW are more likely to be caught by virus signatures. And I'm also having a hard time facing the following problem.
(See also: nim-lang/Nim#17820)

VS2019 also allows you to optionally add a Clang layer, making it compatible with different operating systems but not requiring a dependency on MinGW.
(See also: https://docs.microsoft.com/en-us/cpp/build/clang-support-msbuild)

Please kindly consider this matter.

[Varriount]

It's quite possible to use Clang, rather than GCC, to compile Nim code. You either need to modify nim.cfg, or pass --cc:clang on the command line. I'll admit that there could be improvements here though - the build_all.bat file assumes GCC is being used, for example.

If you're suggesting that Clang be used by default, the problem is that Clang is a compiler, while MinGW is a compiler and SDK. Defaulting to Clang would require users to download the Windows SDK (which is several gigabytes in size, even without Visual Studio).

[rockcavera]

One of the reasons I chose Nim over Rust was the ease of installation on Windows. In other words, for Nim you only had to download the Nim compiler and install Mingw. As for Rust, you had to download an entire SDK and visual studio toolchain. If this change occurs for Clang, which by default uses msvc target and not mingw on Windows, I believe it will have this additional dependency.

I really like Clang and even use it, but Gcc on Windows is still the best option, in my opinion.

[juancarlospaco]

Why not offer binaries built with both GCC and Clang, and let user choose...

[Varriount]

Why not offer binaries built with both GCC and Clang, and let user choose...

Assuming that the MinGW SDK is still being used, what benefit would the choice bring?

[ghost]

Due to lack of feedback from the Nim development team, the proposal will be temporarily withdrawn on July 10, 2021.

[Araq]

Well it's most important to me that the resulting binaries use a libc that comes preinstalled with Windows. If https://docs.microsoft.com/en-us/cpp/build/clang-support-msbuild can deliver that, I'm happy to use it instead.

(I'm part of the development team, so there is no need to withdraw the proposal.)

[ghost]

Thank you, @Araq.

If you have this component installed, you can run clang in the development console as well as MSBuild.
I rewrote the gcc specified in csources and nim.cfg to clang and tried to build it, and the binary was created without any errors.

However, please note that MSVC does not have unistd.h. This is a dependency of MinGW and needs to be resolved.

[rockcavera]

From my experience, it seems that products built with MinGW are more likely to be caught by virus signatures.

I had some extra time and compiled the Nim devel with vcc and clang. I uploaded all the executables (koch.exe, nim.exe, nimsuggest.exe, nimgrep.exe, vccexe.exe, nimpretty.exe, testament.exe, nim_dbg.exe and nimble.exe) to virustotal.com. In the same way that a false positive detection can occur when compiled with GCC, false positive detection occurred for both VCC and CLANG.

Therefore, there is no reason to change the compiler to avoid potential anti-virus detection of false positives. The problem is not there.