"Compiled extensions not installed" warning on Heroku, 0.7.0

[hsm3]

We have a fairly vanilla app deployed on Heroku, cedar stack, and just started using concurrent-ruby. We are seeing logs like this:

Compiled extensions not installed, pure Ruby Atomic will be used. 

There's nothing suspicious in the output from the actual deployment (meaning the git push to heroku).

Is this the correct behavior, or should the C versions be found and used?

[jdantonio]

I'm not sure--I've not tried using this gem on Heroku. We provide precompiled extensions for many platforms (please see the README). On any other platform only pure-Ruby code will be used. I do not know what platform Heroku reports when pulling gems from Rubygems. Presumably what it reports is causing Rubygems to pull the pure-Ruby gem. I will look into this.

In Issue #170 we're discussing the best (most portable) way to handle the native extensions. Please feel free to add your thoughts on that thread.

[hsm3]

Thanks for your quick reply. I don't know much about the underlying mechanics (like what platform Heroku reports), but I can add that there are many gems that come with native code that do work on Heroku (e.g., https://github.com/ohler55/oj). Also, if it helps, our app uses bundler to manage gems, which is also the recommendation on Heroku. Near the top of one of our deployment pushes we see:

-----> Using Ruby version: ruby-2.0.0
-----> Installing dependencies using 1.6.3
Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
Using i18n 0.6.11
Using minitest 4.7.5
.... and so on

[jdantonio]

Gems like OJ force the target system to compile the native code. This means that the target system must have build tools installed. This can be very problematic for many. The build tools on Windows are horrible, very few non-developer users of OS X install Xcode, and many DevOps professionals feel that installing build tools on a production system is a security risk. So we chose to pre-compile then native extensions for multiple platforms. When the gem is downloaded to the target system Rubygems will detect the "platform" (in Ruby/Rubygems terms) and will deliver compiled code for that system. When Rubygems doesn't recognize the platform it will deliver a pure-Ruby gem. The benefit of this approach is hat the target system never has to compile the gem. The risk is that a platform like Heroku--which includes build tools--downloads a pure-Ruby gem even when it is capable of compiling the extensions locally.

Honestly, we're not sure what the best approach is. Basically, native extensions are a problem. We only added them in the latest version because we we were able to get significant performance improvements and much stronger guarantees when setting certain low-level locks.

[jdantonio]

Moved this discussion to #186.

[jdantonio]

@hsm3 I've created a PR which should address this issue in the next major release along with a companion gem for the native C code that would compile on any platform with the necessary build tools (such as Heroku). Would you please give us your feedback on that PR? Thank you!