Thank you for your pull request. We require contributors to agree to our Contributor License Agreement (https://exaloop.io/legal/cla), and we don't have @K0lb3 on file. In order for us to review and merge your code, please email info@exaloop.io to get yourself added.

My first milestone for this PR is that the codon target compiles successfully.
Therefore I "disabled" via comments for now.

llvm and MinGW from choco might be "incompatible" for this project, as the llvm package seems to be targeting msvc.
I'm going to try llvm-mingw as toolchain tomorrow.

@cla-bot check

The cla-bot has been summoned, and re-checked this pull request!

Small update.

GCC x LLVM is quite the pain on Windows.

For GCC and its libs MinGW can be used just fine, but LLVM in combination with that is annoying.
As far as I can see there is no with mingw precompiled llvm with cmake files for Windows.
Due to that either the relevant cmake logic would have to be "ported" to make use of the precompiled llvm-mingw-ucrt,
or llvm would have to be compiled with cmake file generation.

I'm leaning towards the later as I don't want to bother with even more cmake madness.

llvm-mingw doesn't include some header files used by codon,
so llvm compiling it is....

Well, more fun.

llvm-openmp uses an masm format asm for Windows (32x and 64x), and MinGW doesn't ship an masm assembler.
So another requirement for Windows has to be added, a masm compiler...
Let's see if JWasm works.

At the very least arm isn't affected by this, as llvm seems to use a (linux) gcc based asm for it.
How comes this somehow starts to look like a hellhole?

Oh, and to add on top,
cmake seems to detect the asm compiler incorrectly for MinGW, it tries to use gcc instead of as....

long long story

My latest compile history is this (2025/7/18).

exaloop/codon v0.17, MSVC

• Side-projects can be fixed by adjust CPM.cmake, or manually add needed libraries.
• codon/CMakeLists.txt can be adjusted.
• The part need fix is the exceptions in codon/runtime/exc.cpp where it uses unwind.
  Unwind is supported on macOS/Linux, but not supported in Windows UCRT and MinGW/MSYS2.

I also started to adjust some of the dependencies in the cmake/deps.cmake as TaiXeflar mentioned.

Using read.c & allloc.c instead of mmapio.c & mmap.c for backtrace,
switching from exaloop/bdwgc to a newer bdwgc/bdwgc,
using exaloop/openmp as openmp library for __kmpc_set_gc_callbacks.

@K0lb3 Do you joined exaloop/codon's DC server? maybe we can have a chat there

Well, more fun.

llvm-openmp uses an masm format asm for Windows (32x and 64x), and MinGW doesn't ship an masm assembler. So another requirement for Windows has to be added, a masm compiler... Let's see if JWasm works.

At the very least arm isn't affected by this, as llvm seems to use a (linux) gcc based asm for it. How comes this somehow starts to look like a hellhole?

Oh, and to add on top, cmake seems to detect the asm compiler incorrectly for MinGW, it tries to use gcc instead of as....

@K0lb3 have you tried using MSYS2? I see they have the package mingw-w64-x86_64-llvm-openmp in their repository. If you install base-devel package (its dependencies are installed automatically) it provides you with a *nix development environment, but produces native Windows executables. You can install both GCC and clang.

P.S.: don't forget to check this page: Environments.

@MaD70
There's a assembly compile target at openmp/runtime/src/z_Windows_NT-586_asm.asm requires Macro Assembler where GCC toolchain doesn't have this. So is not any environment problems, it is GCC doesn't have Macro Assembler.

Available Macro Assembler is JWasm @K0lb3 using or by MSVC ml64.exe.

@MaD70 There's a assembly compile target at openmp/runtime/src/z_Windows_NT-586_asm.asm requires Macro Assembler where GCC toolchain doesn't have this. So is not any environment problems, it is GCC doesn't have Macro Assembler.

Available Macro Assembler is JWasm @K0lb3 using or by MSVC ml64.exe.

@TaiXeflar obviously you don't know what MSYS2 is and didn’t bother to look at the links I included in my message, did you?

MSYS2 packages are usually precompiled binaries. I quote from MSYS2 home page:

Our package repository contains more than 3500 pre-built packages ready to install.

Follow this link to mingw-w64-x86_64-llvm-openmp package: you'll see there is a separate link to sources and under "Build Dependencies" you'll see there another MSYS2 package listed, mingw-w64-x86_64-uasm, a free MASM-compatible assembler based on JWasm (mingw-w64). If required, the software can be rebuilt from sources from within MSYS2.