2.5.7 CRuby on Windows native extension compilation failing?

[senolfeldmann]

I use CRuby 2.7.3 on Windows 10 x64, nio4r version 2.5.7

Installing the gem on x64 Windows (CRuby with Msys2 toolchain) succeeds just fine. Currently, nio4r is a dependency of puma and actioncable in my project. Everything seems to be working just fine. I noticed that the native extension nio4r_ext.so is 0KB large, namely empty. Is this intended?

My extensions\x64-mingw32\2.7.0\nio4r-2.5.7 folder has two files, gem.build_complete, which is 0KB big, and gem_make.out contains the following:

current directory: C:/Ruby27-x64/lib/ruby/gems/2.7.0/gems/nio4r-2.5.7/ext/nio4r C:/Ruby27-x64/bin/ruby.exe -I C:/Ruby27-x64/lib/ruby/2.7.0 -r ./siteconf20210708-5512-1g08p1p.rb extconf.rb

current directory: C:/Ruby27-x64/lib/ruby/gems/2.7.0/gems/nio4r-2.5.7/ext/nio4r make "DESTDIR=" clean make: *** Keine Regel, um „clean“ zu erstellen. Schluss.

current directory: C:/Ruby27-x64/lib/ruby/gems/2.7.0/gems/nio4r-2.5.7/ext/nio4r make "DESTDIR=" make: Für das Ziel „all“ ist nichts zu tun.

current directory: C:/Ruby27-x64/lib/ruby/gems/2.7.0/gems/nio4r-2.5.7/ext/nio4r make "DESTDIR=" install make: Für das Ziel „install“ ist nichts zu tun.

[ioquatix]

At face value, it won't matter, since it will just fall back to select. Whether this is worth the effort to fix, I'm not sure. Does libev support Windows? I don't think so?

[senolfeldmann]

You are correct, it does not matter at face value. Kernel.select is used as a fallback in this case. It is still confusing that nio4r is trying to compile native extensions under Windows when not needed. I think this issue can be closed.

[ioquatix]

Maybe one option is to disable trying to compile a native extension on Windows, that would make sense to me.