Fix missing rust libs problems, improve caching and refactor compile steps

[waterlink]

• I had a problem when running compiled app on heroku: it wasn't able to find libnative library which is a part of rustc libs directory. After inspecting a slug I understood, that it has no build cache when dyno is running. Resolved issue by copying these libs inside of build directory and sourcing proper LD_LIBRARY_PATH.
• It was a pain to wait for dependencies to be re-downloaded through git and rebuilt from scratch at each deploy. So I put build artifacts (target and $cargo_home) to cache, and on next builds reusing it, so Cargo can decide what to download and what to rebuild on any updates in Cargo.lock file. Turns out that .git folders in cache survive between build perfectly.
• Since bin/compile is too bloated, I have refactored it to different bin/steps/* and call them from bin/compile.

[emk]

Thank you very much for looking into these issues! Sorry I didn't see your pull request earlier.

Can you explain to me what's going on with libnative? The Rust buildpack is supposed to use static linking of all Rust-related libraries. Is this failing for some reason? Is it no longer supported? I really don't want to to copy Rust runtime libraries onto the dynos unless this the new official way that Rust works.

Thank you for helping figure this out. I'll take a a look at the other two patches later—if you don't hear from me by Friday, feel free to ping me again.

[emk]

As for the libnative issue, you may find some clues here: https://github.com/reem/rust-http-content-type/issues/13

Basically, watch out for libraries that are used as both plugins and as regular run-time libraries. These usually wind up having a runtime dependency on syntax, which is not supposed to happen. This is the biggest reason for static linking to fail.

[emk]

Now that @reem has kindly resolved reem/rust-http-content-type#13, all of my Heroku demo programs can be linked statically. So here's what I'm thinking:

1. The refactoring looks nice, and I think I'll incorporate it.
2. The build cache will be super-useful. Thank you very much!
3. For now, I'm probably going to continue to rely on static linking, and I recommend that you check for bogus dependencies on syntax. But if there's a compelling reason to support shared libraries, I'm happy to reconsider.

Once again, thank you for your contributions!

[emk]

Upon further examination, it looks like the first patch in the stack is the one which copies over the shared libraries, and the two patches I want to merge first both depend on that one. If you feel like making a standalone version of https://github.com/johnmq/heroku-buildpack-rust/commit/99a2b911df32ba71b3bfc7d43e32ccc5748300a1 , I'll happily merge it. If not, I'll try to extract the necessary bits myself when I have a spare moment.

Once again, many thanks!

[waterlink]

I will make a standalone version soon

Best Regards, Alexey Fedorov, Sr Ruby Developer, Clojure Developer, +49 15757 486 476

2014-11-05 13:36 GMT+01:00 Eric Kidd notifications@github.com:

Upon further examination, it looks like the first patch in the stack is the one which copies over the shared libraries, and the two patches I want to merge first both depend on that one. If you feel like making a standalone version of johnmq@99a2b91 https://github.com/johnmq/heroku-buildpack-rust/commit/99a2b911df32ba71b3bfc7d43e32ccc5748300a1 , I'll happily merge it. If not, I'll try to extract the necessary bits myself when I have a spare moment.

Once again, many thanks!

— Reply to this email directly or view it on GitHub https://github.com/emk/heroku-buildpack-rust/pull/2#issuecomment-61800731 .

[emk]

OK, I really owe you some major apologies for a slow followup to this pull request. I'm not quite sure what the current status is, but I believe it might be obsoleted by the current move to Rustup.

If you'd still like to merge some form of this PR, feel free to reopen this PR.

Thank you for submitting a PR, and my apologies for not finding the time to update this way back when.