-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building on Windows - CMake? #87
Comments
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 |
|
@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!
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 If that is the case, I will continue with adding the other build steps. |
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 |
@thepowersgang Done. Now there is a huge list in I opened a WIP pull-request, so it's easier to talk about changes: #88 |
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. |
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. |
@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. |
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) |
@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). |
@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. |
@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 |
@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. |
There's a PR #184 to update to a newer MSVC, and the windows build should always at least manage to compile cargo. |
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 ofcommon.lib
does not match the location of the 64-bit build.Unresolved externals to
HIR::ExprPtr::get_mir_or_error_mut
and othersThere is a call to
HIR::ExprPtr::get_mir_or_error_mut
incleanup.cpp
, insideMIR_CleanupCrate
. The linker complains about it not findingget_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:
The text was updated successfully, but these errors were encountered: