search

terralang / terra

Terra is a low-level system programming language that is embedded in and meta-programmed by the Lua programming language.
terralang.org
Other
2.72k stars 201 forks source link

End Visual Studio's reign of terror once and for all #411

Closed ErikMcClure closed 5 years ago

ErikMcClure commented 5 years ago

This commit correctly finds all versions of Visual Studio back to 2010, at least in theory. It first replaces the old method of finding a registry value with a proper implementation of a registry key query and uses that to find either the 8.1 or 10.0 version of the Windows SDK. It then adds an entire header file and function that wades through the sheer insanity that is the Visual Studio COM object setup, which attempts to find either 2017, 2019, or any future version. If this fails, it falls back to the registry method to query visual studio versions all the way back to 2010. Hopefully the directory structure didn't change past 2013, because if it did this won't work.

The native tools detection is kept intact, because if Microsoft loses their mind again and changes everything in a future version of visual studio, it will be the only way to find anything.

This also removes CUDA headers entirely if cuda is not present and passes the target architecture into getvclinker() so that cross-compilation actually works correctly on windows by using a linker that actually matches the target architecture. This is mostly to support compiling arm, since that's the only architecture other than x64 anyone would actually target on windows.

elliottslaughter commented 5 years ago

Looks fine so far. Let me know if you have any trouble with the rebase.

elliottslaughter commented 5 years ago

@blackhole12 Are you happy with the PR at this point or do you have more to do here?

ErikMcClure commented 5 years ago

I think this PR is ready to be merged, if you don't see any problems with it.

elliottslaughter commented 5 years ago

I'm fine with everything here, I mainly just wish we had VS2017/2019 tested in appveyor. But like I said before we have no LLVM builds available on those versions right now, so there's nothing to do there until we get that....

If you feel like fixing that, let me know, otherwise I'll go ahead and merge this.

ErikMcClure commented 5 years ago

I'm not really sure that's actually a problem? I am currently using the exact same LLVM build used for Visual Studio 2015 on my machine with no complaints. I'm going to try to just add Visual Studio 2017/2019 to appveyor and see what happens.

elliottslaughter commented 5 years ago

By all means, if you think it might actually work then let's go for it. I guess I'd just assumed LLVM builds would not be compatible across VS versions.

ErikMcClure commented 5 years ago

VS2017 is failing with what appears to be a monumentally stupid error: Visual Studio 2017 is missing a critical DLL when cross-compiling. It appears that AppVeyor is running these VMs as 32-bit, or at least the tests are being run as 32-bit. VS2019 contains mspdb140.dll in all cases, but VS2017 is missing them for cross-compilation cases, and terra is trying to compile everything to x64 no matter what.

Assuming this is the actual error (I can't check the host architecture to confirm it), I'm not really sure how to fix it other than either support VS2019 only, or convince appveyor to compile things on the native architecture.

elliottslaughter commented 5 years ago

Question: if someone installed VS2017 on their own machine (with 64-bit OS) would it work, at least hypothetically? If it's just AppVeyor being weird, it doesn't really bother me. We don't need to work around AppVeyor's problems. I mostly just want it to be well-tested-enough that we catch any mistakes before they make it into the code base.

ErikMcClure commented 5 years ago

Hypothetically this should work so long as someone is running it on a 64-bit machine and isn't trying to cross compile. However, I found a workaround that Rust uses where they simply... add the native toolchain to the path directory of the cross-compile toolchain, which is kind of insane, but I'm going to give it a shot anyway.

ErikMcClure commented 5 years ago

All tests now pass and this PR is ready to be merged (one travis test had a spurious URL failure).

As a side-note, the reason LLVM works even when compiled with Visual Studio 2015 is because the toolset major version hasn't changed yet. LLVM compiled with 14.0 is ABI compatible with 14.1 and 14.2, at least for now. If Microsoft makes a breaking change, a recompilation will be necessary, but until then, this will make it easier to add LLVM 8 support, because you only have to compile LLVM 8 once, using Visual Studio 2015, and it'll work on 2015/2017/2019.

elliottslaughter commented 5 years ago

Thanks, merged it.