Splitting WindowsToolchain #65
Closed
MarkSchofield
started this conversation in
Ideas
Replies: 1 comment
-
https://github.com/MarkSchofield/WindowsCMake has been split off from https://github.com/MarkSchofield/WindowsToolchain |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
"WindowsToolchain" started as - essentially - my home-grown, minimal build environment. I wanted the fast, cheaply authored, incremental build that CMake+Ninja gets, but for building Windows projects - that may include, say, CppWinRT/IDL/NuGet-like things. As a result, WindowsToolchain currently has two jobs:
The project attempts to differentiate the two jobs by having the main toolchain, and then 'Support' files for opt-in things. But the "CMake Toolchain" job is better defined than the "CMake conveniences and support" job. The former should be stable, relatively unchanging with a minimal 'surface area'. The latter should be progressive and grow over time to keep-up with changes in Windows build constructs/tooling.
Based on these requirements and constraints I think it would be best to split the project in two. "WindowsToolchain" should be a minimally sufficient CMake Toolchain that is relatively unchanging. Folks bringing projects from, say, MacOS or Linux-based CMake builds should be able to have a consistent experience on Windows just by specifying the WindowsToolchain. Then the 'opt-in' pieces can move to a new project - say, "WindowsCMake" - that brings Windows build constructs (like CppWinRT/IDL/NuGet-like things) to a non-VS Generator CMake build.
I think this will bring stability and minimal 'surface area' to the WindowsToolchain to help fix #18 and #50 and decouple from churn in "WindowsCMake".
What do folks think?
Beta Was this translation helpful? Give feedback.
All reactions