c3lang
Move away from Visual Studio on Windows
Asking for Visual Studio on Windows might be a common thing to do, but its awful in terms of user experience. Visual Studio is a bloated huge dependency to ask for, especially given that other options are available:
- https://msys2.org
- https://github.com/mstorsjo/llvm-mingw
- https://ziglang.org (can act as a C compiler)
all of which have a footprint one or two orders of magnitude smaller than Visual Studio.
It is already possible to use mingw. BUT that said it is not an ideal solution since using MSVC is guaranteed to be the most compatible. Also, the plan is to allow the compiler to download the necessary VS files.
download the necessary VS files
from my understanding, this has never been possible. From my experience, Visual Studio is only available as an installer, which differs from the other options I listed, which are available as a Zip file or similar that you can extract. Also, again the size is hugely different. For example, LLVM-MinGW is about 115 MB:
https://github.com/mstorsjo/llvm-mingw/releases/tag/20220802
whereas Visual Studio is about 100 times that size.
If you don't want to install all of Visual Studio, you can also use the "Buildtools for Visual Studio" (https://aka.ms/vs/17/release/vs_BuildTools.exe). In the installer, select "Desktop development with C++".
This seems to work for both using the precompiled binaries as well as compiling C3 yourself.
@kstrb no thank you. The Visual Studio environment, even just the buildtools, is a bloated and poorly designed system for compiling C programs. Even the buildtools installer edits registry entries and modifies environment variables, among other system changes. Contrast with the other options I listed, in which you simply extract and run the compiler. I would only use Visual Studio if I had no other choice. Hopefully this will be considered in the future.
I am also not happy about the size and "invasiveness" of it, but it's the only Microsoft-sanctioned way. I just came to terms with it being the cost of doing business on Windows. But yeah, I would also love an official, lean option...
The problem is with linking. If you want to be able to link MSVC without running into bugs in some cases, then you use the MS libraries. And not all of those are available for free distribution. Compressing all the possible files I could need for linking I only get 100 MB worth of data. Unfortunately, I can't provide that as a public download without violating the MS terms of service.
@89z, To try to improve this, I've lately released a script to pull in dependencies. It's a python script that is bundled with the binaries msvc_build_libraries.py. If you run it from the same directory as c3c.exe it should build you a msvc_sdk folder with all of the .lib files that you need for windows linking. The compiler will automatically look for msvc_sdk relative to the .exe, so this should allow you to build without VS or VS build tools. Note that you still need to agree to the MSVC license. Incidentally, this script can also be run on Mac and Linux to allow cross compilation to Windows.
thats very interesting, however I would still like to see a non Visual Studio version if possible. If you comment this line:
https://github.com/c3lang/c3c/blob/15586b3076e729649dcc79b8ac2b35f8a33274d1/msvc_build_libraries.py#L235-L237
you see that the script actually downloads about 1.16 GB worth of stuff. So even with this optimized script, you're still pulling down about 10 times what you would using LLVM-MinGW or similar. That is an impressive script, but ultimately I am appreciating you engineering a very good bandage, over a very bloated system. Ideally that system wont be used in the first place.
LLVM MinGW is essentially grabbing the same thing but with worse compatibility and not all of the .lib files. I'm saying worse compatibility because of what I read Zig is running into: https://github.com/ziglang/zig/issues/9998
Using the native .libs is sort of the holy grail, because it doesn't make you dependent on updates by a third party and you can work with everything from OS prereleases to old versions. If C3 would depend on MingW, then that is essentially running C3 on compatibility mode on Windows. I want C3 to be a first class language on both Windows and MacOS, and you can't do that unless you really link to the real thing.
So yes, it's a big download, and keeping the libraries around is a cost, but that has to be balanced against the benefit of having perfect compatibility.
It might be interesting to contrast Zig, Odin and C3:
- Zig is in somewhat Linux first, then compatibility with Windows and MacOS, and an underlying goal is to try to abstract away as much as possible for cross compilation, in order to make it "just work" as far as possible.
- Odin doesn't care about cross compilation and doesn't really support it well. It's Windows first, making it a nice Windows alternative.
- C3 cares about cross compilation and tries to support it well, it's Mac and Windows first, with less emphasis on Linux. In general it wants to cross compile to Mac and Windows, but doesn't care that much in terms of being able to cross compile to Linux and making Linux apps.
I should also mention that I originally had Mingw support in the compiler but have been dropping that.
Hey, I have you seen this:
https://github.com/ziglang/zig/issues/9998#issuecomment-997401665
that could be a good compromise!
Basically what the commenter is looking for is what's already achieved for C3. In regards to "Mingw being better than Windows".
For C3 the libs are simply used to link to dlls on Windows without needing to actually download said dlls, just like the SDK the script does. So what Mingw brings to the game is SIMPLY reverse engineered .lib files unencumbered by licensing restrictions. You can (but you do not have to) use its crt. Furthermore, Mingw does this only for a subset of all the Windows .lib files available. By adding more stuff (like MSYS) you can have some POSIX functionality as well, but essentially it's about getting those .libs that describe .dlls.
Now since mingw actually reverse engineer things to get those .libs and MSVC has the originals, I don't see how the former could be better.
I don't wish to continue the previous line of points. I think we've both made our sides known, and good points have been made on both sides. I think the open source nature of MinGW-w64 is a huge selling point on its own, as it significantly improves the distribution process. I would ask you review my last comment, where I linked to a comment about a Nuget package that could be a good compromise solution - it seems to be a minimal set of Visual Studio files for just compiling and/or linking. It seems to be quite small at under 200 MB total download.
NuGet is another third party solution. It's possible that it can be used, or maybe it can't. If someone makes a compelling script for it that is competitive with what we currently have, then I'll look into it.
@89z I appreciate that you're so invested in improving the download footprint for windows compilation. The current script is a beginning and no means the endgame, but with limited resources "good enough" has to be sufficient until the compiler has reached such maturity that there is opportunity to add further polish to these parts.
So I find the current status quo is sufficient, esp when comparing to Zig, which has been in development since 2016 and has tons of people contributing and several people doing it full time.
LLVM MinGW is essentially grabbing the same thing
Can you clarify what you mean here? Are you implying that llvm-mingw pulls down the official Windows SDK somehow - because it most definitely doesn't do that.
@mstorsjo No, I meant that Mingw provides the same thing as downloading the .lib files from MSVC: a way to link objects files into .exes that rely on Win32 OS DLLs. The benefit of using Mingw is that rather than having license restricted .lib one links using the mingw libs that work the same way. Just two ways of getting the same thing.
@mstorsjo No, I meant that Mingw provides the same thing as downloading the .lib files from MSVC: a way to link objects files into .exes that rely on Win32 OS DLLs. The benefit of using Mingw is that rather than having license restricted .lib one links using the mingw libs that work the same way. Just two ways of getting the same thing.
If it's not the same license, then how can it be the "same thing"?
Honestly I am not totally opposed to the msvc_build_libraries.py solution, but I think it could be improved a little. I wrote a similar script a year ago, that was more aggressive on what packages were chosen. I think I got the download to about 300 MB or so. Something like that would be more reasonable. Or maybe the Nuget packages I mentioned earlier - those are quite small, and they are made by Microsoft as well.
- https://nuget.org/packages/Microsoft.Windows.SDK.CPP
- https://nuget.org/packages/Microsoft.Windows.SDK.CPP.x64
@89z Yes, there are several improvement points:
- Weed out unnecessary MSVC .lib files.
- See if the download can be completely implemented in C so it can be done by the compiler.
- Check if simpler solutions exist that still download from MSVC
- Have the mingw solution as an alternative for those who want.
@89z: Hey, thanks for the tip regarding the Nuget packages, that looks actually easy to work with!
(Edit: it seems like the core MSVC libs are not available as nupkg. A pity, that solution would have been nice...)
Here is another good option:
https://github.com/Jake-Shadle/xwin
using this command:
xwin download
You get a resulting folder of 288 MB, much smaller than msvc_build_libraries.py
I think this one is essentially doing what the script does with some further pruning. What I want is to essentially get this script either into .c or .c3 form with no dependencies. Unfortunately that means writing libraries for all the functionality it relies on. It would be worthwhile doing it for .c3 for the standard library, less so for .c. Xwin here is using a long list of Rust crates.