search

danielpclark / rutie

“The Tie Between Ruby and Rust.”
MIT License
942 stars 62 forks source link

build.rs refactor #75

Closed danielpclark closed 5 years ago

danielpclark commented 5 years ago

pkg-config-rs was only using the system's install Ruby when linked with cargo:rustc-link-lib=dylib=ruby-2.5 and failed otherwise requiring the libruby.so file to be in the target/<PROFILE>/deps dir.

Linux build systems (at least recent Ubuntu versions) don't search for the Ruby library at all in the search path provided in cargo:rustc-link-search=native=/some/path or cargo:rustc-link-search=dependency=/some/path or cargo:rustc-link-search=/some/path. This requires that for the Linux OS we need to provide a symbolic link to the libruby.so file in the target/<PROFILE>/deps dir. The down side to this approach is if you dynamically change which Ruby version you are using in the console it will likely not be the same as the one that Rutie is linked to. I have implemented a test for this in src/lib.rs that will alert the developer when this occurs.

Since pkg-config-rs had a well designed cflag parser which works well to takes the cflags Ruby has readily available and make them compatible with the Rust build process I have copied that bit of code into the build.rs library. Since pkg-config-rs is dual licensed with the option of the MIT LICENSE I've adhered to that license by copying the author tag/copyright line into our own MIT LICENSE. Because of this feature now being added in we will have all of the specific OS flags for compilation correctly given to us and no longer need to implement them ourselves.

danielpclark commented 5 years ago

Okay, now that the pkg-config-rs stuff is out of the way along with some weird behavior being gone we have an honest fail on Ruby 2.4.5. Three methods of which we have issues open #43, #44, and #45 are revealed to not be working on that version of Ruby. This was likely always the case but due to how linking with Ruby was working before we couldn't tell as it was likely linking to the system's installed Ruby rather than the one from RVM… but that's just a guess. … Or maybe that version of Ruby just needs to be compiled (--disable-binary) … yeah, I think that's more likely the case.

The main issue in this PR is needing to get Ruby 2.6.0 working with Mac OS. I'm fairly sure it's the ruby lib name being passed to the linker. It may have finally changed.

danielpclark commented 5 years ago

Okay. Now only Mac OS with Ruby 2.6 needs to be fixed.