MSVC support #2015
Comments
…definitions I'm using conan-provided system dependencies since package deps won't work
|
I managed to compile on MSVC by adding macro definitions to avoid the winsocket redefinition issues. |
|
(CCing @larskanis who know more about Windows than I do and may be able to help.) Hi, @jmarrec, thanks for opening this issue. It looks like you've jumped to a solution in #2016, which is great, thank you -- but I'd like to have a conversation here to more deeply understand the problem you're trying to solve. Your comments here, and in the PR, about I don't know what If that we can restate the problem without |
|
In the meantime, I've started the process of downloading and installing a Windows 10 virtualbox VM with VS 2019 to try to reproduce what you might be seeing. That will ... take some time. |
|
@flavorjones yeah thanks for getting back to me, and I apologize is this is somewhat messy :) I'm going to quote something I wrote in #2016 so it's all here:
TL;DRSo to summarize:
|
|
@jmarrec Thanks for the additional context. I'll note that If you'd like to remove the I'll update #2016 with this note as well. |
…definitions Note: jaro_winkler is a native gem dependency of rubocop that currently doesn't supports C89 (MSVC) I'm using conan-provided system dependencies since package deps won't work
…definitions Note: jaro_winkler is a native gem dependency of rubocop that currently doesn't supports C89 (MSVC)
Are you interested in testing with mswin in CI? |
|
Added a TODO to the OP above with three items, only one of which is addressed in #2016. |
|
Thanks. I know you've used Concourse-CI for a while, and times are different now. Actions is a bit different, and some of the problems people had with AppVeyor & Travis are now being handled by Ruby people. |
|
I successfully mix MSVC compiled binaries into MINGW code in several projects and it should work the other way around as well. That's what I usually recommend users, when a library isn't available/compatible for the particular platform. Regarding MSVC support in nokogiri I can not really help - I don't use MSVC and don't have any interest in doing so. But sure, I'll keep maintaining the MINGW port. |
|
I'd like to close this, as I'm not sure what remains to be done and I am unaware of any ongoing work in this area. If MSVC still does not compile Nokogiri, I'm open to a PR that addresses the issue, but I won't be doing that work myself and so I'd like to close this issue or find an owner who's willing to commit to defining and finishing the work. I'd expect setting up CI for MSVC to be part of that work, both to demonstrate the problems and to demonstrate that they've been solved. |
|
1.11.0 and 1.11.1 can not be installed on MSVC. # ext/nokogiri/extconf.rb
# Before
# ensure_package_configuration(opt: "zlib", pc: "zlib", lib: "z", headers: "zlib.h", func: "gzdopen")
# After
# The change maybe affect other platforms, I’m not sure
ensure_package_configuration(opt: "zlib", pc: "zlib", lib: "zlib", headers: "zlib.h", func: "gzdopen") |
|
OK, I'm going to close this for the reasons I've mentioned above. Once again, I'm open to PRs that address specific MSVC issues, but then I would like these each treated as separate, addressable issues -- using the bug report or installation problem templates -- so that we understand the failure modes and can have a conversation about how to fix it. What I really want is someone to help set up CI of some kind on MSVC so that we have a feedback loop on proposed and actual changes. This is an opportunity for people who depend on MSVC to show up in the community and contribute. @KoellM if you'd like to have a conversation about the failure you're trying to address with the suggested patch, can you please open a new "installation difficulties" issue, and include all the necessary logs from the failed install? Thanks. |
Testing against Ruby mswin master can be done with GitHub Actions. ruby/openssl has been doing it for quite a while, see: |
|
@MSP-Greg thanks once again for being a voice in support of Github Actions. If you want to submit a PR introducing MSVC test into the CI suite (is that the same as |
|
@MSP-Greg maybe here I should also qualify my remarks: I'd like some way to validate that CI is reproducing what MSVC users are doing in the real world. Which is why I keep asking Windows users to do this work. I want to avoid the antipattern of spending time setting up a red build, then spending time getting red to green, and then discovering that real-world cases are actually harder/simpler/different. How can we mitigate that risk? |
TODO
.cross-rubiesandtask/cross-ruby.rbwould be modified to allow MSVC gems to be packaged.Describe the bug
I found the similar #255 which is from 2010 and seemed to imply MSVC support was achieved, yet it isn't.
I realize this is rather a corner case, but it's one I am in: I have to use MSVC to compile this gem as we have a C++ application that has to be built on MSVC and one thing it does is to create a CLI based on ruby and embedded some gems.
To Reproduce
bundle installfailed.gem 'jaro_winkler', '= 1.5.4', :github => 'jmarrec/jaro_winkler', :ref => 'f1ca425fdef06603e5c65b09c5b681f805e1e297'toGemfilebundle installworksbundle exec rake compilewill fail right away due to the unability to compile the packaged libs (zlib and co) with the currentextconf.rbconanto download the dependencies (zlib, xml2, and xlst/exlst)I created a
conanfile.txtlike thisInstall dependencies and activate the build env
Realized it wouldn't still find the exslt lib due to the naming of the libs, so just cp them to a new name
Ok, try compilation again:
Output:
Expected behavior
Ideally Nokogiri would built out of the box on MSVC.
Environment
Windows 10 x64. Ruby compiled locally with MSVC 2019 16.5
$ ruby -v
ruby 2.5.5p157 (2019-03-15) [x64-mswin64_140]
$ gem list
*** LOCAL GEMS ***
ast (2.4.0)
bigdecimal (default: 1.3.4)
bundle (0.0.1)
bundler (2.1.4)
cmath (default: 1.0.0)
concourse (0.31.0)
csv (default: 1.0.0)
date (default: 1.0.0)
docile (1.3.2)
fiddle (default: 1.0.0)
fileutils (default: 1.0.2)
hoe (3.22.1)
hoe-bundler (1.5.0)
hoe-debugging (2.0.0)
hoe-gemspec (1.0.0)
hoe-git (1.6.0)
io-console (default: 0.4.6)
ipaddr (default: 1.2.0)
json (default: 2.1.0)
mini_portile2 (2.5.0)
minitest (5.14.0)
openssl (default: 2.1.2)
parallel (1.19.1)
parser (2.7.0.5)
psych (default: 3.0.2)
racc (1.4.16)
rainbow (3.0.0)
rake (13.0.1)
rake-compiler (1.1.0)
rake-compiler-dock (1.0.1)
rdoc (6.2.1, default: 6.0.1)
rexical (1.0.7)
rexml (3.2.4)
rubocop (0.80.1)
ruby-progressbar (1.10.1)
scanf (default: 1.0.0)
simplecov (0.18.5)
simplecov-html (0.12.2)
sync (0.5.0)
term-ansicolor (1.7.1)
tins (1.24.1)
unicode-display_width (1.6.1)
webrick (default: 1.4.2)
The text was updated successfully, but these errors were encountered: