Trying to get build_target.py working for libraries with build scripts

[Andrew Walbran]

Hello,

In the Rust DDK, we have build scripts set in our Cargo.toml which compile a small C file which needs to be linked with the rest of the Rust library to load the driver properly. So far for development we've been building everything with fargo, but I'd like to get it working via BUILD.gn too. You can see an example of such a build script at https://fuchsia.googlesource.com/garnet/+/master/public/rust/crates/ddk-rs/examples/microorb/build.rs.

This currently fails (after fixing a few other issues) with the build script failing to find the C source file under src/binding.c. This appears to be because build_target.py runs cargo from out/release-x86-64/gen/garnet/public/rust/crates/ddk-rs/ddk-rs.rust/ rather than from the actual source directory garnet/public/rust/crates/ddk-rs/examples/microorb. In particular it passes args.gen_dir to run_command as the pwd when running cargo. Why is it doing this? This also seems to make everything else more complicated, with all the logic to 'fix' paths in the Cargo.toml by prepending a bunch of stuff to them. Why not just run cargo in the directory where the source files actually are, like normal?

[Tim Kilbourn]

I can't address all the reasons our GN build is so complicated, but to replace build.rs, you can probably define a static_library() with binding.c in it and just link it in somehow when your rust lib is created. I don't know if that's supported already, but it will be "soon".

--
You received this message because you are subscribed to the Google Groups "rust-fuchsia" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rust-fuchsia...@fuchsia.com.
To post to this group, send email to rust-f...@fuchsia.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.com/d/msgid/rust-fuchsia/CA%2B_y_2G0ikiz%2BcDg3gX1rAPiZxtAGWKwUeT0261G6yvvO4FXVg%40mail.gmail.com.

[James Tucker]

aside: looks like `via` re-appeared, remind me, i'll take another look.

We've been discussing moving to make build.rs work in our builds, but we need to first do a better job at isolating $PATH and doing some work to ensure that we don't end up with pkg-config psuedo working, etc.

What is the urgency of this request?

On Tue, Nov 7, 2017 at 11:25 AM, 'Tim Kilbourn' via rust-fuchsia <rust-f...@fuchsia.com> wrote:

I can't address all the reasons our GN build is so complicated, but to replace build.rs, you can probably define a static_library() with binding.c in it and just link it in somehow when your rust lib is created. I don't know if that's supported already, but it will be "soon".

On Tue, Nov 7, 2017 at 10:30 AM 'Andrew Walbran' via rust-fuchsia <rust-f...@fuchsia.com> wrote:

Hello,

In the Rust DDK, we have build scripts set in our Cargo.toml which compile a small C file which needs to be linked with the rest of the Rust library to load the driver properly. So far for development we've been building everything with fargo, but I'd like to get it working via BUILD.gn too. You can see an example of such a build script at https://fuchsia.googlesource.com/garnet/+/master/public/rust/crates/ddk-rs/examples/microorb/build.rs.

This currently fails (after fixing a few other issues) with the build script failing to find the C source file under src/binding.c. This appears to be because build_target.py runs cargo from out/release-x86-64/gen/garnet/public/rust/crates/ddk-rs/ddk-rs.rust/ rather than from the actual source directory garnet/public/rust/crates/ddk-rs/examples/microorb. In particular it passes args.gen_dir to run_command as the pwd when running cargo. Why is it doing this? This also seems to make everything else more complicated, with all the logic to 'fix' paths in the Cargo.toml by prepending a bunch of stuff to them. Why not just run cargo in the directory where the source files actually are, like normal?

--
You received this message because you are subscribed to the Google Groups "rust-fuchsia" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rust-fuchsia+unsubscribe@fuchsia.com.

To post to this group, send email to rust-f...@fuchsia.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.com/d/msgid/rust-fuchsia/CA%2B_y_2G0ikiz%2BcDg3gX1rAPiZxtAGWKwUeT0261G6yvvO4FXVg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "rust-fuchsia" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rust-fuchsia+unsubscribe@fuchsia.com.

To post to this group, send email to rust-f...@fuchsia.com.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.com/d/msgid/rust-fuchsia/CAKUMrDvxjkNGtgoqBGdewmyBg0Pe%3DgwjetHNWWTGLYxrKV3wVg%40mail.gmail.com.

[Andrew Walbran]

On 7 November 2017 at 19:25, Tim Kilbourn <tkil...@google.com> wrote:

I can't address all the reasons our GN build is so complicated, but to replace build.rs, you can probably define a static_library() with binding.c in it and just link it in somehow when your rust lib is created. I don't know if that's supported already, but it will be "soon".

Will that work with fargo as well? I'd like to keep both workflows working for development.

 

On Tue, Nov 7, 2017 at 10:30 AM 'Andrew Walbran' via rust-fuchsia <rust-f...@fuchsia.com> wrote:

Hello,

In the Rust DDK, we have build scripts set in our Cargo.toml which compile a small C file which needs to be linked with the rest of the Rust library to load the driver properly. So far for development we've been building everything with fargo, but I'd like to get it working via BUILD.gn too. You can see an example of such a build script at https://fuchsia.googlesource.com/garnet/+/master/public/rust/crates/ddk-rs/examples/microorb/build.rs.

This currently fails (after fixing a few other issues) with the build script failing to find the C source file under src/binding.c. This appears to be because build_target.py runs cargo from out/release-x86-64/gen/garnet/public/rust/crates/ddk-rs/ddk-rs.rust/ rather than from the actual source directory garnet/public/rust/crates/ddk-rs/examples/microorb. In particular it passes args.gen_dir to run_command as the pwd when running cargo. Why is it doing this? This also seems to make everything else more complicated, with all the logic to 'fix' paths in the Cargo.toml by prepending a bunch of stuff to them. Why not just run cargo in the directory where the source files actually are, like normal?

--
You received this message because you are subscribed to the Google Groups "rust-fuchsia" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rust-fuchsia+unsubscribe@fuchsia.com.

[Andrew Walbran]

On 8 November 2017 at 07:17, James Tucker <ra...@google.com> wrote:

aside: looks like `via` re-appeared, remind me, i'll take another look.

We've been discussing moving to make build.rs work in our builds, but we need to first do a better job at isolating $PATH and doing some work to ensure that we don't end up with pkg-config psuedo working, etc.

What is the urgency of this request?

It's not super urgent at the moment, but it would make the development cycle easier. It's also a prerequisite to including any real drivers written in Rust into the build, though there may be policy issues with that anyway.

[Tim Kilbourn]

No, that would not work with fargo. Since the binding file is pretty trivial, I was thinking it wouldn't be the end of the world to maintain both build.rs and the BUILD.gn rules.

On Wed, Nov 8, 2017 at 11:08 AM Andrew Walbran <qwa...@google.com> wrote:

On 7 November 2017 at 19:25, Tim Kilbourn <tkil...@google.com> wrote:

I can't address all the reasons our GN build is so complicated, but to replace build.rs, you can probably define a static_library() with binding.c in it and just link it in somehow when your rust lib is created. I don't know if that's supported already, but it will be "soon".

Will that work with fargo as well? I'd like to keep both workflows working for development.

 

On Tue, Nov 7, 2017 at 10:30 AM 'Andrew Walbran' via rust-fuchsia <rust-f...@fuchsia.com> wrote:

Hello,

In the Rust DDK, we have build scripts set in our Cargo.toml which compile a small C file which needs to be linked with the rest of the Rust library to load the driver properly. So far for development we've been building everything with fargo, but I'd like to get it working via BUILD.gn too. You can see an example of such a build script at https://fuchsia.googlesource.com/garnet/+/master/public/rust/crates/ddk-rs/examples/microorb/build.rs.

This currently fails (after fixing a few other issues) with the build script failing to find the C source file under src/binding.c. This appears to be because build_target.py runs cargo from out/release-x86-64/gen/garnet/public/rust/crates/ddk-rs/ddk-rs.rust/ rather than from the actual source directory garnet/public/rust/crates/ddk-rs/examples/microorb. In particular it passes args.gen_dir to run_command as the pwd when running cargo. Why is it doing this? This also seems to make everything else more complicated, with all the logic to 'fix' paths in the Cargo.toml by prepending a bunch of stuff to them. Why not just run cargo in the directory where the source files actually are, like normal?

--
You received this message because you are subscribed to the Google Groups "rust-fuchsia" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rust-fuchsia...@fuchsia.com.

[Andrew Walbran]

On 8 November 2017 at 19:56, Tim Kilbourn <tkil...@google.com> wrote:

No, that would not work with fargo. Since the binding file is pretty trivial, I was thinking it wouldn't be the end of the world to maintain both build.rs and the BUILD.gn rules.

True. But as it stands the BUILD.gn rules still use the Cargo.toml, and so try to use build.rs and fail.

 

On Wed, Nov 8, 2017 at 11:08 AM Andrew Walbran <qwa...@google.com> wrote:

On 7 November 2017 at 19:25, Tim Kilbourn <tkil...@google.com> wrote:

I can't address all the reasons our GN build is so complicated, but to replace build.rs, you can probably define a static_library() with binding.c in it and just link it in somehow when your rust lib is created. I don't know if that's supported already, but it will be "soon".

Will that work with fargo as well? I'd like to keep both workflows working for development.

 

On Tue, Nov 7, 2017 at 10:30 AM 'Andrew Walbran' via rust-fuchsia <rust-f...@fuchsia.com> wrote:

Hello,

In the Rust DDK, we have build scripts set in our Cargo.toml which compile a small C file which needs to be linked with the rest of the Rust library to load the driver properly. So far for development we've been building everything with fargo, but I'd like to get it working via BUILD.gn too. You can see an example of such a build script at https://fuchsia.googlesource.com/garnet/+/master/public/rust/crates/ddk-rs/examples/microorb/build.rs.

This currently fails (after fixing a few other issues) with the build script failing to find the C source file under src/binding.c. This appears to be because build_target.py runs cargo from out/release-x86-64/gen/garnet/public/rust/crates/ddk-rs/ddk-rs.rust/ rather than from the actual source directory garnet/public/rust/crates/ddk-rs/examples/microorb. In particular it passes args.gen_dir to run_command as the pwd when running cargo. Why is it doing this? This also seems to make everything else more complicated, with all the logic to 'fix' paths in the Cargo.toml by prepending a bunch of stuff to them. Why not just run cargo in the directory where the source files actually are, like normal?

--
You received this message because you are subscribed to the Google Groups "rust-fuchsia" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rust-fuchsia+unsubscribe@fuchsia.com.