Cross-Compilation: Windows on Mac

[syntonica]

I'm currently using mingw on Win10 with either CodeBlocks or Geany. I forget--that's how long it's been since I've touched my PC! On my Intel Mac, I'm using a slightly older version of Xcode.

I just discovered that Homebrew for Mac has a mingw-w64 package that I can install. IIRC, mingw has all the required header files and whatnot, though I'm not fully familiar with what goes on under the hood when linking, so I'm unsure what else I might need. I think I can even do my basic testing under Wine before even having to have to drag out my PC.

Questions are:
Is anyone else doing this, or similar?
How is it working for you?
What other files might I require?

Alternatives:
Given the mingw header sets, is there a way to use Mac clang to do the compilation?
Might I be better off just biting the bullet and installing Win10 in VirtualBox?

Thanks!

[FigBug]

While I'm sure it's possible, I can't see how setting this up is a useful way to invest your time. You'll still need a Windows machine for testing. Do your builds on github actions or a VM.

[syntonica]

I do all my dev on the Mac. I've tried git and other VCSs and they just don't work for me. It's overkill for me for a handful of files.

My code is at the point where I don't need to make any Windows-specific changes and it's just faster and easier to compile in situ than to futz with moving my code back and forth when I can just work from a single code base. If my plugin runs on Wine, then I can copy it over to the PC and test it with all the DAWs.

Which reminds me: I'll have to check on Wine and 64-bittedness.

[rafa1981]

I do it from Linux, but probably it works with Mac after tweaking. There is a Rust utility called "xwin" that handles downloading the Windows SDK and CRT and fixing it for a case-sensitive filesystem.

https://github.com/Jake-Shadle/xwin

With the win SDKs, clang-cl and a CMake toolchain file your project might compile for Windows. This is how I build MixMaxtrix, which is a Juce based project.

https://github.com/RafaGago/artv-audio/ ... hain.cmake

With that I have a Linux-only compilation chain. I don't do Mac though, but maybe this approach works.

EDIT: seeing that you don't like version control, probably you can't tolerate CMake (notice that I don't say like, it is implied that no one likes that crap).

[syntonica]

EDIT: seeing that you don't like version control, probably you can't tolerate CMake (notice that I don't say like, it is implied that no one likes that crap).

Version control is fine, I'm just a lone wolf programmer, so I don't need to share. If I was in a team or had a huge codebase, I'd use it.

I only hate cmake because when I homebrewed it, it downloaded everything that wasn't nailed down, and then took like 6 hours to compile... I just hate bloat and that's bloat.

I'll just stick with make if I ever feel the need to script my compilation.

Thanks for the tip on the SDKs. Hopefully, I won't need anything that heavy, but if you can cross-compile on Linux, then I can probably do it on Mac.

[mystran]

EDIT: seeing that you don't like version control, probably you can't tolerate CMake (notice that I don't say like, it is implied that no one likes that crap).

Version control is fine, I'm just a lone wolf programmer, so I don't need to share. If I was in a team or had a huge codebase, I'd use it.

It's not just about sharing, it's a complete game changer even for a lone developer. Not only does it trivialize sync across computers (eg. if you have a desktop and a laptop), even on a single computer it gives you a safety net where you'll always have access to any past version, with quick diffs, with blame (when did I change this line of code), so you don't need to bother with inconvenient manual backups and it makes it very simple to do new development, even stuff that temporarily completely breaks your codebase, while simultaneously maintaining another branch where you can fix bugs in your currently released version (which you can then also merge into your development branch without having to do the work twice).

You don't necessarily need to use a service like github and even if you do, you don't necessarily need to go all out with dev-branches and formal pull-requests. Even just committing directly to the master (whether local or hosted) will get you huge benefits. Having clean commits is nice whenever you need to go back through the history, but it's not critical, even just dumping your current state of codebase once per day into a repository is infinitely better than not using anything.

The thing is.. I've never heard of a developer that doesn't use any source control. Making backups (or ZIPs) of your source tree is a form of source control too, just a terrible one.

[DNAdisaster]

To second mystran's sentiment, version control really is useful even if you're a team of one. It may just be me, but I often experiment into unknown territory and mess things up that were previously working. It's very nice to be able to commit checkpoints and revert to the last working version of code. That being said, I don't think ZIPs are terrible--if that's what works for you, it works. But being able to diff and review previous commit messages is very nice. I know this is getting a little off topic to your original question. Unfortunately I know very little about cross-compilation, but I can point you to AppVeyor as a free Windows CI service. It won't help you with testing, but will at least get you a Windows build. I use it in one of my plugins, and you can see my config file here if that's any help (it does use CMake, but at least it's running on someone else's computer : https://github.com/austensatterlee/VOSI ... pveyor.yml.

[rafa1981]

+1 to version control.

You don't need CMake for compilation, but at least a decent Makefile and being proficient in compilation, so you can set CXX, LD, AR and probably something more to the clang-cl variants, add some include and linker paths to CXXFLAGS and LDFLAGS, etc.

In my case, if mine weren't a Juce project I wouldn't probably use CMake either.

[syntonica]

+1 to version control.

I just make zips whenever I start anything more than simple but fixes. Any major branches get a special name so I know how far back I need to go if things go pear-shaped.

Believe me, I tried SVC,git, Mercurial and a couple others, both locally and on a server. In the end, it was much ado about nothing for me, far more trouble than it was worth. I just need to remember to backup my zips religiously, which is far easier than backing up a local repository.

I've been thinking about how I can, given Windows SDKs and stuff are installed, set it up in Xcode using clang as just another build. I'll have to see how my Windows project is set up.

Have I mentioned how much I hate developing on my PC? Even if I did have a served version of version control, I'd still hate working in Windows. I used to do a ton of admin work in Windows 7 and XP and it was a constant fight trying to get things done, especially when I had to use the crappy tools provided versus the native tools and where each physical location had their own special way of doing things. Just logging into my Windows 10 machine brings back the memories. Is it possible that I have M$PTSD?

I joke, but I know that many of y'all feel much the same about having to work on a Mac and probably wish you could compile locally on your Windows machine, especially if you are using a cross-platform framework, like Juce or iPlug. I'm sure it's possible as well, although I'm unsure of how deep the rabbit hole goes once you invoke Cocoa.

[mystran]

+1 to version control.

I just make zips whenever I start anything more than simple but fixes. Any major branches get a special name so I know how far back I need to go if things go pear-shaped.

This is a form of version control. It's just about the most terrible form of version control, but it's a form of version control.

Believe me, I tried SVC,git, Mercurial and a couple others, both locally and on a server. In the end, it was much ado about nothing for me, far more trouble than it was worth. I just need to remember to backup my zips religiously, which is far easier than backing up a local repository.

Here's the thing: use a remote master... and now backup is a matter of "git push" .. and it's an offsite backup if you're pushing to an offsite server... and it takes basically no time whatsoever, 'cos it'll only transfer the diffs.

There are benefits for trying to maintain clean commit history, but for quick&dirty "don't care" approach you'll basically say "git add -u; git commit -m 'foobar'; git push" once a day and you'll always have up to date offsite backups, in a form that are way easier to deal with (even with this terrible way of committing "whatever") than any zip-files ever.

[rafa1981]

Edited this while in reality I wanted to answer, so some part of the message is lost.

You don't need clang, but clang-cl. I don't know if you can use the cl frontend for clang on the version provided by xcode.

[mystran]

You don't need clang, but clang-cl. I don't know if you can use the cl frontend for clang on the version provided by xcode.

That's not quite accurate. You just need clang/LLVM that is built to target Windows. The "clang-cl" front-end is just a command-line wrapper that allows you to use MSVC "cl.exe" style flags, you can use regular "clang" (with traditional unix-style command-line options) on Windows too (which is what I do, 'cos it plays better with a cross-platform Makefile). Beyond different command-line syntax, there's no real difference that I know of between the two and it only really matters at all if your using a built-system that wants to use one set of flags or another.

XCode actually doesn't even (strictly speaking) ship with "clang" but rather "Apple clang" which for all intents and purposes is a fork and as far as I know it's not going to target Windows no matter what... but you should be able to install another clang for cross-compilation if you truly think it's worth it.

[Chaotikmind]

You just need clang/LLVM that is built to target Windows

you don't need a specially build version of clang since it is inherently a cross-compiler

i directly cross-compile from windows to qnx with an out of the box clang here.

[mystran]

You just need clang/LLVM that is built to target Windows

you don't need a specially build version of clang since it is inherently a cross-compiler

i directly cross-compile from windows to qnx with an out of the box clang here.

You don't need a "special" build, but you do need a build with the targets enabled when LLVM was built. In other words, you can include just about every target in a single build of LLVM, but that doesn't mean that every built of LLVM has to support every target. Your stock QNX compiler was apparently compiled to include Windows support, but the one that ships with XCode is not.

[syntonica]

Apple clang already targets Intel. I'm not sure what else a build of it would need to support Windows, except possibly 32-bit if Apple stripped support out completely. However, I don't think they'll do that any time soon.