3 ms·

Color me surprised. As a developer, the number of times "Windows support" or "MSVC" is the special case that requires you to go through contortions.. shrug I

Color me surprised. As a developer, the number of times "Windows support" or "MSVC" is the special case that requires you to go through contortions.. shrug It's been very frustrating on multiple open source projects I've worked on, people proposing to change entire build systems of projects just so that MSVC can be included as a build target. I hope the new Bash-on-Windows stuff will eventually make supporting MSVC a little simpler from various Unix-oriented build tools.

burntsushi 10y ago
Yeah, I'm especially bitter because I just spent my entire weekend getting colors and tty detection to work consistently in Windows. It was unbelievably hard. (The central difficulty is that you need to support both native Windows consoles like cmd.exe and cygwin terminals like mintty.) It's worth it though. There are lots of people on Windows! And thankfully, most of the other pieces (like the build system) in Rust are cross platform by default. :-)
tedmielczarek 10y ago
Supporting Windows is often a pain (although in this case Rust hides a lot of that pain, honestly), but the main driver of the original sccache implementation was not Windows support, but the ability to share the compilation cache across our many ephemeral build machines. My colleague Mike Hommey (who wrote the first implemenation) has some nice graphs demonstrating this in his original blog posts on the topic: https://glandium.org/blog/?p=3079 https://glandium.org/blog/?p=3079
quotemstr 10y ago
Meanwhile, GCC works fine on Windows. (Mingw builds normal non Cygwin programs.) There's no need to bow to cl.exe just because you want to build for Windows
- tedmielczarek 10y ago
  If you're shipping binaries to end users Microsoft's optimizer is pretty fantastic, especially if you build with PGO. Plus MinGW sometimes lags behind with things added in newer Microsoft SDKs, so there can be some friction there. I think things are getting better with clang-cl, so that might be a feasible direction in the near future.
  - deleted 10y ago
    [deleted]

burntsushi 10y ago

Yeah, I'm especially bitter because I just spent my entire weekend getting colors and tty detection to work consistently in Windows. It was unbelievably hard. (The central difficulty is that you need to support both native Windows consoles like cmd.exe and cygwin terminals like mintty.) It's worth it though. There are lots of people on Windows! And thankfully, most of the other pieces (like the build system) in Rust are cross platform by default. :-)

tedmielczarek 10y ago

Supporting Windows is often a pain (although in this case Rust hides a lot of that pain, honestly), but the main driver of the original sccache implementation was not Windows support, but the ability to share the compilation cache across our many ephemeral build machines. My colleague Mike Hommey (who wrote the first implemenation) has some nice graphs demonstrating this in his original blog posts on the topic: https://glandium.org/blog/?p=3079 https://glandium.org/blog/?p=3079

quotemstr 10y ago

Meanwhile, GCC works fine on Windows. (Mingw builds normal non Cygwin programs.) There's no need to bow to cl.exe just because you want to build for Windows

tedmielczarek 10y ago
If you're shipping binaries to end users Microsoft's optimizer is pretty fantastic, especially if you build with PGO. Plus MinGW sometimes lags behind with things added in newer Microsoft SDKs, so there can be some friction there. I think things are getting better with clang-cl, so that might be a feasible direction in the near future.
- deleted 10y ago
  [deleted]