-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking crates with exotic build.rs #41
Comments
https://github.com/briansmith/ring/blob/master/build.rs is a doozy, it's upstream of actix-web :| |
Got an initial read of that thing? Does it look like we can run it if we provide the right env vars? |
It might, wanted to keep track before I got the chance to take a deeper look. |
A few notes from my attempt at looking at
The latter 3 are needed by the gcc invocation. Apparently,
HTH |
Howdy! I didn't see any special handling for backtrace or backtrace-sys in the crater or other examples, but with my dependency on the failure crate I'm getting backtrace 0.3.9 and backtrace-sys 0.1.23 as transitive dependencies. This version of backtrace-sys has been renovated compared to 0.1.16: I'm unable to link or build any crate (aka all of my crates at the moment) due to missing symbols:
Adding the following to my raze Cargo.toml has had no effect at all:
|
This requires building it's c portion explicitly, we've done this
internally I'll try to share it
…On Wed, Aug 1, 2018, 09:42 Chip Collier ***@***.***> wrote:
Howdy!
I didn't see any special handling for backtrace or backtrace-sys in the
crater or other examples, but with my dependency on the failure crate I'm
getting backtrace 0.3.9 and backtrace-sys 0.1.23 as transitive dependencies.
This version of backtrace-sys has been renovated compared to 0.1.16:
https://github.com/alexcrichton/backtrace-rs/blob/master/backtrace-sys/build.rs
I'm unable to link or build any crate (aka all of my crates at the moment)
due to missing symbols:
<snip gobs of linker output/>
undefined reference to `__rbt_backtrace_create_state'
undefined reference to `__rbt_backtrace_pcinfo'
undefined reference to `__rbt_backtrace_syminfo'
collect2: error: ld returned 1 exit status
Adding the following to my raze Cargo.toml has had no effect at all:
[raze.crates.backtrace-sys.'0.1.23']
gen_buildrs = true
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#41 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACLjeKoayjaDkpHFR7SXXjkBUjvMpNvTks5uMbBfgaJpZM4TCCJs>
.
|
I see. I'd just be adding a new rule more or less replicating the effect of the build.rs then? And does that require fooling with output from cargo-raze? |
cargo/Cargo.toml
cargo/overrides/backtrace-sys-0.1.23/ contains a copy of the crate, with the following added cargo/overrides/backtrace-sys-0.1.23/BUILD which is a modification of the generated file
This magical series of steps should be improved by #58 |
Thanks for so quickly sharing your solution @mfarrugi. I would not have worked this out so fast on my own. |
Ran into new build scripts! Our solution was to hardcode the Edit:
|
I needed to link libsqlite3-sys, and found that it uses some interesting bindgen options that I couldn't replicate via bindgen executable flags: Specifically, it overrides the integer type inference via a callback passed to the bindgen library to cause the |
@acmcarther I am currently trying to get Did you somehow solve the problem? |
@sirwindfield
|
For completeness, here's our current raze Cargo.toml: third_party/rust/cargo/Cargo.toml
third_party/rust/cargo/overrides/backtrace-sys-0.1.23/BUILD
third_party/rust/cargo/overrides/libloading-0.5.0/BUILD
this also serves as some additional context for #58 |
@vitalyd covered almost all of the changes needed to get ring to compile. In order to address the |
I tried the suggestions from #41 (comment) and #41 (comment) could not get ring to build.
|
I think it'd be really useful to have an example in this repository for how to write a |
@prestonvanloon were you able to make any more progress on ring? I'm running into the same issue you have. |
I don’t recall reaching a solution. Gave up on rust with bazel for now |
@mfarrugi Did you try getting openssl working with boringssl? It's especially convenient since they maintain a bazel branch. |
Nope, was addressing a specific internal requirement by linking to system
openssl.
…On Fri, Dec 20, 2019 at 11:08 PM Joseph Price ***@***.***> wrote:
@mfarrugi <https://github.com/mfarrugi> Did you try getting openssl
working with boringssl? It's especially convenient since they maintain a
bazel branch.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#41?email_source=notifications&email_token=AAROG6B4FF2GCKYXNNHY35TQZWJDVA5CNFSM4EYIEJWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHOUS6A#issuecomment-568150392>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAROG6EVNFEFJ7VIMT4MEA3QZWJDVANCNFSM4EYIEJWA>
.
|
No problem. I'll keep smashing my head against it. I'm also hitting a glorious infinite loop when trying to compile unicase with the error "calls in statics are limited to constant functions, tuple structs and tuple variants". |
Has anyone gotten backtrace-0.3.4 to compile with bazel? I keep getting the below errors.
and my cargo.toml is as follows.
|
@kornholi I tweaked Then I stuck with |
With the latest changes to rules_rust and cargo-raze I was able to remove all the tweaks and build with just |
The latest changes are amazing and solved most of the issues in my project. However, for some reason the default build script generated by cargo raze for libusb1-sys 0.3.7 hangs forever while building. (context, I am trying to build a project that depends on rusb 0.6 I tried adding the system Example `Cargo.toml` file to reproduce[package]
name = "LibUSB_App"
version = "0.1.0"
[lib]
path = "fake_lib.rs"
[dependencies]
rusb = "0.6"
byte_struct = "0.4.2"
[raze]
workspace_path = "//cargo"
output_buildfile_suffix = "BUILD.bazel"
default_gen_buildrs = true |
couple notes for people who have some of the issues I had:
for anyone running into issues with native-tls (macos build), i had to manually import all of it's extern crate dependencies:
and add them as additional deps
|
An interesting example I've found amethyst which has a lot of sys dependencies. I thought it would be clever to pull them in rules_nixpkgs:
However actually configuring them as dependencies on each of the sys crates has proven difficult. Are there any recommendations on how debugging / identifying configuration options and specific flags. So far I've been using `bazel query deps(//3rdparty/cargo:amethyst)' to find the quickly identify dependent crates, but I don't know how to go about actually finding all the necessary flags or options. |
Do you have `nix-shell --command 'cargo build'` working for amethyst? If
that works, you can run cargo build -v to print out the flags.
…On Thu, Sep 10, 2020 at 10:03 PM epigramengineer ***@***.***> wrote:
An interesting example I've found amethyst
<https://crates.io/crates/amethyst> which has a lot of sys dependencies.
I thought it would be clever to pull them in rules_nixpkgs
<https://github.com/tweag/rules_nixpkgs>:
rules_nixpkgs_version="dc24090573d74adcf38730422941fd69b87682c7"
rules_nixpkgs_sha256="aca86baa64174478c57f74ed09d5c2313113abe94aa3af030486d1b14032d3ed"
http_archive(
name = "io_tweag_rules_nixpkgs",
strip_prefix = "rules_nixpkgs-{0}".format(rules_nixpkgs_version),
url = "https://github.com/tweag/rules_nixpkgs/archive/{0}.tar.gz".format(rules_nixpkgs_version),
sha256 = rules_nixpkgs_sha256,
)
***@***.***_tweag_rules_nixpkgs//nixpkgs:repositories.bzl", "rules_nixpkgs_dependencies")
rules_nixpkgs_dependencies()
***@***.***_tweag_rules_nixpkgs//nixpkgs:nixpkgs.bzl", "nixpkgs_git_repository", "nixpkgs_package")
nixpkgs_git_repository(
name = "nixpkgs",
revision = nixpkgs_version,
sha256 = nixpkgs_sha256,
)
nixpkgs_package(name = "alsa-lib", repository = ***@***.***")
nixpkgs_package(name = "cmake", repository = ***@***.***")
nixpkgs_package(name = "expat", repository = ***@***.***")
nixpkgs_package(name = "openssl", repository = ***@***.***")
nixpkgs_package(name = "pkg-config", repository = ***@***.***")
nixpkgs_package(name = "python3", repository = ***@***.***")
nixpkgs_package(name = "vulkan-validation-layers", repository = ***@***.***")
nixpkgs_package(name = "xorg.libX11", repository = ***@***.***")
However actually configuring them as dependencies on each of the sys
crates has proven difficult. Are there any recommendations on how debugging
/ identifying configuration options and specific flags. So far I've been
using `bazel query deps(//3rdparty/cargo:amethyst)' to find the quickly
identify dependent crates, but I don't know how to go about actually
finding all the necessary flags or options.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#41 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAROG6DQ43QWQC5HTC7X73TSFGAPDANCNFSM4EYIEJWA>
.
|
We dropped google/cargo-raze and adapted the build-strategy of project-oak, by simply referencing the generated artifacts (cargo-build) # These files are built via cargo outside of Bazel
exports_files(srcs = glob(["target/x86_64-unknown-linux-musl/release/*"])) It just works. Messing around Cargo, bazelbuild/rules_rust and google/cargo-raze is an absolute waste of time, energy, resources and money. |
The trade-off is ease of use and interop (rust <=> c, etc).
At a glance it looks like oak dropped the target they needed rules_rust &
raze for recently and so removed unused dependencies. Their exports_files
implies they are only using binary outputs, which would be straightforward.
…On Sat, Oct 10, 2020 at 7:47 AM cherryland ***@***.***> wrote:
We dropped google/cargo-raze and adapted the build-strategy of project-oak
<https://github.com/project-oak/oak>, by simply referencing the
*generated* artifacts (cargo-build
<https://doc.rust-lang.org/cargo/commands/cargo-build.html>)
# These files are built via cargo outside of Bazel
exports_files(srcs = glob(["target/x86_64-unknown-linux-musl/release/*"]))
It just works.
Messing around Cargo, bazelbuild/rules_rust and google/cargo-raze is an
absolute waste of time, energy, resources and money.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#41 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAROG6H5LIFRULSUISTHISLSKBCUTANCNFSM4EYIEJWA>
.
|
I'm trying to get But the build fails with:
This is with
in the
I assume I've missed something obvious, but for the life of me I can't see what it is. Anyone got any pointers? |
This was fixed earlier today by bazelbuild/rules_rust#439 |
@mfarrugi That's great, thanks for the pointer. Do you think it would be worthwhile adding a repository where people can submit the overrides that they've determined need to happen, and integrating that in to For example, I've just discovered that to build the
To discover that I had (a) diagnose the build failure, (b) poke through the The fix above is going to need to be done by anyone who wants to use that crate with Note that the above works with a version of I.e., with this in the
And with this it doesn't:
224fe6a81b8ffa9c585c75f49a41f9b9924d516d over there is the commit that breaks it, I've tested other commits up to and including the one immediately preceding it, 9c889b057ddf4feddae7c5ae6913b7282154aa24, and they work. More details in bazelbuild/rules_rust#467 |
@nikclayton-dfinity That would be amazing. Maybe in here? https://github.com/acmcarther/cargo-raze-crater/tree/master/cargo |
We should consider moving that half-baked thing into this repo (probably outside of impl/, unless we're really good and can integrate these into raze's generation step... which would be awesome) |
Another useful source of rules -- Fuschia uses GNaw, which is like https://fuchsia.googlesource.com/fuchsia/+/master/third_party/rust_crates/Cargo.toml is their equivalent of the workspace |
Another snowflake package is |
khronos_api seems to be another one.
works to some extent, but the build.rs generates lots of
Found when trying to compile smithay |
Tried to build with a modified build.rs, still didn't find a way:
|
@sinkingpoint managed to fix khronos_api build with these changes: kshcherban/gl-rs@1a3d96c |
Moving acmcarther/cargo-raze#16 over here.
Bazel needs some extra help with build.rs scripts that:
Conveniently I haven't run into many additional problems, and our set of overrides hasn't grown.
The text was updated successfully, but these errors were encountered: