| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Gem will be ready to release once ruby/syslog#28 merges. I will re-push this PR to switch to the gem at that point. |
Sorry, something went wrong.
|
Still waiting on ruby/syslog#28. @hsbt What can I do to help get a new syslog gem released? |
Sorry, something went wrong.
|
Just released https://github.com/ruby/syslog/releases/tag/v0.4.0 |
Sorry, something went wrong.
|
@hsbt Wonderful, thank you! I will release future version for JRuby changes as needed. |
Sorry, something went wrong.
|
This is ready to go. |
Sorry, something went wrong.
|
Ok maybe not... |
Sorry, something went wrong.
The RubyGems we run at build time runs with JRuby 9.4, which causes it to use properties from that version for things like gem paths and extension directories. This is related to the extension disabling change in jruby#8415 and causes the build-time extension faking to use the wrong path. For example: .../gems/shared/extensions/universal-java-25/3.1.0 when it should be .../gems/shared/extensions/universal-java/3.4.0 The change here uses RubyGems' cross-compiling capability by forcing a specific rbconfig.rb to be use, and additionally fakes out the Ruby API version by setting @ruby_api_version on the Gem module. This was discovered while attempting to switch fully to the syslog gem in jruby#9109, since as a bundled gem it will not be activated unless we successfully fake-out the extension build. See also this bug related to the resolv gem installing extensions: * jruby#8649
The RubyGems we run at build time runs with JRuby 9.4, which causes it to use properties from that version for things like gem paths and extension directories. This is related to the extension disabling change in jruby#8415 and causes the build-time extension faking to use the wrong path. For example: .../gems/shared/extensions/universal-java-25/3.1.0 when it should be .../gems/shared/extensions/universal-java/3.4.0 The change here uses RubyGems' cross-compiling capability by forcing a specific rbconfig.rb to be use, and additionally fakes out the Ruby API version by setting @ruby_api_version on the Gem module. This was discovered while attempting to switch fully to the syslog gem in jruby#9109, since as a bundled gem it will not be activated unless we successfully fake-out the extension build. See also this bug related to the resolv gem installing extensions: * jruby#8649
It only defined constants from jnr-constants, which we can do in Ruby.
Because of the issue described in an fixed by jruby#9197, the fake-out of the syslog extension build fails. Because it was being installed as a bundled gem rather than a default gem, and RubyGems will not activate a gem whose extension has not been built, this prevented syslog from being loadable. The change here moves it to a default gem for now, so that it can still be loaded from stdlib as well as being upgraded by users. These changes should be reverted once the gem platform fix has been merged.
The RubyGems we run at build time runs with JRuby 9.4, which causes it to use properties from that version for things like gem paths and extension directories. This is related to the extension disabling change in jruby#8415 and causes the build-time extension faking to use the wrong path. For example: .../gems/shared/extensions/universal-java-25/3.1.0 when it should be .../gems/shared/extensions/universal-java/3.4.0 The change here uses RubyGems' cross-compiling capability by forcing a specific rbconfig.rb to be use, and additionally fakes out the Ruby API version by setting @ruby_api_version on the Gem module. This was discovered while attempting to switch fully to the syslog gem in jruby#9109, since as a bundled gem it will not be activated unless we successfully fake-out the extension build. See also this bug related to the resolv gem installing extensions: * jruby#8649
| Back | FazBrowse Home | New Git URL |
This PR will eventually switch us to the syslog gem, once our FFI-based version has been incorporated.
See ruby/syslog#1