-
-
Notifications
You must be signed in to change notification settings - Fork 75
Native crate support #54
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
…. even if the important bit is just whether it compiles or not
@softprops, after reading this, I wonder if we shall add this to the
And then on |
sorry for the delay. I'll try to take a closer look into this with in the coming week. |
Yay, thanks @softprops! Looking forward to have this merged in :) |
👋 |
Sorry for the delay on this. There's actually a proposal that might help for custom dependency needs #6 |
Oh yeah, that one looks neat! OTOH, my PR is really just including clang in the mix, that's a pretty common base requirement I reckon? :-S |
Noticed the |
I understand the point made in #53 (divergence from upstream lambda environment/image)... OTOH, a quite rust-official docker container that cannot compile That being said, let me refresh this branch a bit, there might be a more acceptable workaround than pulling in more deps than strictly necessary. If that works I can close this PR with some peace of mind about this ;) |
Coincidentally that native rust crate requires docker to build (because cross and MUSL), so the level of inception would get a bit too ridiculous when combined with this builder XD And now I understand what you mean, this is only meant to be a runtime environment, not a build-time env, closing. |
Fixes issue #53, where an old LLVM/clang version was preventing rust-htslib crate from compiling inside the docker container.
Might affect other bindgen crates in the future so it is worth having
llvm-config
et al present on$PATH
and reasonably up to date, imho.Perhaps that clang version should be updated accordingly upstream on
lambci
container itself as well?