Building on Windows - CMake?

[ataulien]

I tried to compile mrustc a couple of times now for windows (my work machine), but unfortunately I did not succeed.

Stuck on VS2015's compiler

The build only works with the Compiler from VS2015 (v140), which is what is set inside the projects. When switching the setting to VS2017 (v141) or Clang, the build is missing zlib, which is supposedly pulled in via NuGet. It seems that there is no zLib-package on NuGet for v141 so the build just fails when including a zlib-header.

I am not too experienced with NuGet on C++ and I could not find a workaround for that (manually downloading zlib would work I suppose).

Wrong directories for 32-bit target

When trying to compile as 32-bit, VS complains about not finding common.lib, even though it is being built. The problem here is that the library output location for a 32-bit build of common.lib does not match the location of the 64-bit build.

Unresolved externals to HIR::ExprPtr::get_mir_or_error_mut and others

There is a call to HIR::ExprPtr::get_mir_or_error_mut in cleanup.cpp, inside MIR_CleanupCrate. The linker complains about it not finding get_mir_or_error_mut, which I could not find the reason for.
I can grab the exact build error when I'm at work again next week, but I remember VS looking for a function with __cdecl-calling convention, when it should rather be a __thiscall...

No CI for Windows

The excellent AppVeyor provides CI for Windows builds free of charge for Open Source-projects. Is there any reason this has not been set up yet other than "nobody bothered yet"? If the latter is true, I would go ahead and set it up if I can get the windows build going on my own machine.

Switch to CMake?

Right now, the project ships with makefiles and a Visual Studio solution. If you think it would be worth a try, I would set up CMake for mrustc to see if it would make building easier for all platforms.

If you have never worked with CMake, here are some features which I think could help the project from the top of my head:

• One of the most used build-systems in the C/C++ world these days
• Not depending on any IDE or compiler
• Cross-platform downloading files with checksum-tests
• Streamlines build process on each platform
• Can generate "install"-targets which makes packaging easy

[strega-nil]

I think Meson would also be a good choice to think about. I'd be totally willing to set up a PR for compiling it this way.

One thing I'd like to remind people is that all of these options are installable with pip.

[thepowersgang]

• VS2017 support: I'm using VS2015 Community for my windows development, so that's what it targets :) The intention of using nuget for zlib was to make it be auto-magical, if that isn't working then I have no idea.
• bad target directories for Win32: I blame visual studio, Fixed in 4d6aa11
• get_mir_or_error_mut - The build error should be fixed now, it was caused by a mismatch between class/struct (which changed the mangled function names) - Should be fixed in 9dd5e53
• No CI - Yep, it's just because nobody has been bothered to set it up. That, and the MSVC builds aren't quite working yet (some tests are failing).
• CMake - I've not used it much, but feel free to give creating a cmake structure a try?

[ataulien]

@ubsan I have never worked with Meson before, sorry

@thepowersgang Thanks for the quick fixes! I will try and see if I can build on windows when I can!
In the meantime, I went ahead and forked the repository to build a cmake-project. It is able to:

• Download rustc-sources (cross-platform)
• Read Git-Information
• Build Common-library
• Build minicargo
• Build Standalone MIRI
• Build Testrunner
• Build mrustc

I added some instructions on how to build using cmake to the readme in my fork: https://github.com/ataulien/mrustc/tree/cmake

Can you please skim over the various CMakeLists.txt and let me know whether this is something you are ok working with?

If that is the case, I will continue with adding the other build steps.

[thepowersgang]

From a quick look, it looks good. Just maybe not have src/CMakeLists.txt defer to other files (instead list all files in the per-executable CMakeLists.txt

[ataulien]

@thepowersgang Done. Now there is a huge list in src/CMakeLists.txt.

I opened a WIP pull-request, so it's easier to talk about changes: #88

[ataulien]

As we now have two PRs, one with CMake (#88) and one with Meson (#89), I think @thepowersgang should decide whether/which one should be used in mrustc so we don't do the same work twice.

[thepowersgang]

My rough preference is for CMake. Even if Meson is more technically advanced, cmake is a requirement for building llvm/rustc so is already (effectively) a dependency.

I'm open to good arguments the other way though.

[strega-nil]

@thepowersgang I would argue that it isn't actually that big of a deal to call into cmake from meson, and that it's an incredibly minor issue to actually install meson, therefore we should use the better one. I think you'll agree that the meson build system is far more readable, and would probably be easier to edit - and all of the weird stuff is written in python, which most people know (as opposed to cmake). It's also actually going to set versions every time, but only compile that file again - a recompile where nothing has changed takes around 2 seconds, as it's only a recompile of version.cpp, and then a re-link.

Also, if you do end up writing some Rust, meson does support Rust, unlike CMake.

[thepowersgang]

I'm still not sold on the advantages of adding both the meson package and python to the build are, over just adding cmake to handle the C++ code (minicargo can handle the rest, with a little help from cmake to invoke it)

[strega-nil]

@thepowersgang I mean, I personally don't find the CMake that readable or editable. If you disagree, you're totally welcome to use it (although make certain that the version stuff works - it does under meson, but I don't believe it'll work under cmake without rebuilding the build system every time).

[ataulien]

@ubsan I'm trying my best to write the CMakeLists as clean as possible and the scripts I wrote for mrustc are really simple and readable, at least I thought they were. Could you please elaborate on which parts you do not understand and find unreadable? This would help me, as I'm always trying to avoid writing code which people cannot understand.

The git-script will detect when HEAD changes and update the cache accordingly. There is no need to regenerate the build system manually.

[strega-nil]

@ataulien it's more like "CMake is unreadable by virtue of being CMake", rather than "your CMake in specific is unreadable".

That's fair, I just wanted to be sure.

The only major actual issue that I see, besides it being CMake, is that in the main add_executable, you pass raw files, while in the tools, you pass strings for files.

[eddyp]

@ataulien @thepowersgang what's the status on Windows builds?

I'm very curious how hard would it be for mrustc to generate code for non-x86 targets and non-GNU compatible C compilers on Windows host.

[thepowersgang]

There's a PR #184 to update to a newer MSVC, and the windows build should always at least manage to compile cargo.