search

rake-compiler / rake-compiler-dock

Easy to use and reliable cross compiler environment for building Windows, Linux, Mac and JRuby binary gems.
MIT License
77 stars 30 forks source link

prepare for Ruby 3.2 support #76

Closed flavorjones closed 1 year ago

flavorjones commented 1 year ago

This issue is a placeholder for a conversation about Ruby 3.2 support.

This year, I'd like to be able to cut a release of rake-compiler-dock shortly after Ruby 3.2 final is released.

To that end, I'd also like us to consider shipping a "release candidate" of rake-compiler-dock for downstream users to test with and give feedback on.

@MSP-Greg, do you expect any Windows-specific challenges for this release? I'm looking at https://github.com/MSP-Greg/ruby-loco/releases and it looks like we may need to support ucrt, mswin, and mingw? Are there documents you can point me at so I can build more context?

MSP-Greg commented 1 year ago

do you expect any Windows-specific challenges for this release

Not sure about Rust gems. Otherwise, I don't think I've needed to make any major changes to ruby-loco in quite a while.

we may need to support ucrt, mswin, and mingw?

Not sure, up to you. The only popular public Windows release will be RubyInstaller2's ucrt build. @larskanis ?

But, there are people using mswin builds, I quickly threw up https://github.com/MSP-Greg/ruby-mswin/releases, and will probably try to keep mswin builds available. As to mingw, not sure, I suspect most people have switched to ucrt, but ruby/ruby runs CI against all three (ucrt, mswin, and mingw) in master...

A few years ago, it was very difficult to build ext gems with mswin. Now, Microsoft/vcpkg has a lot of packages available.

RubyInstaller2 builds have ridk enable to set the env for the MSYS2 build tools (mingw or ucrt). When using mswin, the user needs to enable the msvc builds tools. As you've probably seen, using setup-ruby in Actions does that in its code. That has confused a few people trying to do things locally.

I haven't worked that much with rake-compiler-dock, but I do have all the build tools installed locally, both Windows & WSL2/Ubuntu...

larskanis commented 1 year ago

do you expect any Windows-specific challenges for this release?

There is one bigger change in RubyInstaller-3.2, which is OpenSSL-3.0. It's changes pass through to the Ruby API, which makes it partly incompatible and requires such patches. However this change to RubyInstaller doesn't change anything to RCD, since we don't provide any libraries for bundling into binary gems.

it looks like we may need to support ucrt, mswin, and mingw?

RCD already supports mingw only for ruby up to 3.0 and ucrt for 3.1. Ruby master is no longer tested on mingw - only ucrt and mswin. I personally have no interest on supporting mswin in RubyInstaller or RCD. So also no changes from my POV.

The issues I'd like to have fixed are:

All the above are unrelated to the particular ruby-3.2 release, but I often used to do such changes when adding a new ruby release.

MSP-Greg commented 1 year ago

it looks like we may need to support ucrt, mswin, and mingw? Ruby master is no longer tested on mingw

Thanks for pointing that out, I wasn't aware of that. Happened about 3 weeks ago...

Re OpenSSL 3, I recently noticed that you were building head with it. As we get closer, setup-ruby will need to grab the package. I suppose that could be done now for the Ruby head build. Haven't seen any indication of when MSYS2 will be changing to OpenSSL 3, have you? MSFT's vcpkg already has...

ianks commented 1 year ago

Another big request I have is to add linux/arm64 Docker images. Currently, building on M1 is unbearably slow in many cases due to the virtualization overhead. I’ve almost given up on running RCD locally as a result.

flavorjones commented 1 year ago

See #82 which is a naive first pass at 3.2 support.

flavorjones commented 1 year ago

3.2 support is merged in #82 and #83. I'm going to close this since 3.2 was the intent of this issue; but obviously we should try to get some of the other things listed in here in the next version.