beyond-all-reason / beyond-all-reason/RecoilEngine
Possibility of llvm-mingw as a toolchain replacement for linux/windows builds?
- Dominant language
- C++
- Stars
- 679
- Forks
- 290
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 40
Description
### Context
unwritten for now
### Initial Findings
some findings from me looking into llvm-mingw as an alternative for our gcc setup:
- one single **modern** distro in a docker image for all builds, including **arm for windows** (is that important?)
- use whatever latest version of llvm-mingw we want, and we'd probably want libc++ not libstdc++ for the std library
- we can use the sysroot from Ubuntu 18.04 to maintain compatibility, but requires us to compile libc++ from llvm sources against the sysroot.
- the nice thing is, unlike gcc, ONLY the std library needs to be compiled and otherwise clang/llvm itself doesn't need to be.
- Alternatively we can use the baked in libstdc++ in the sysroot, but then we can't rely on any language features that internally call the std lib. Maybe we want to avoid that anyways so this is fine.
- we can generate both dwarf and codeview pdb symbols for windows
- we get the latest set of language features (and optionally std library) from clang, easily upgradeable ongoing (since the toolchain versions are separate from the std library versions)
Contributor guide
Research direction
Start by reviewing the current GCC setup for Linux and Windows builds, then evaluate the proposed llvm-mingw Docker image, sysroot compatibility, libc++ build requirements, and symbol formats. Done means reaching a documented decision on whether llvm-mingw can replace the current toolchain and identifying the migration work required.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, docker
- Domain
- build-system, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100