RFC Greater customization of cargo

[epage]

Use cases

• Specifying features (see Allow CommandCargoExt to pass build arguments #34)
• Depending on which we keep as default, either (see main_binary should reuse the caller's target #4)
  • Specify the target to get cross-compilation coverage and improve cross-compilation test performance
  • Don't specify the target to improve naive-compilation test performance

Considerations

• The primary use case of assert_cmd is testing Rust binaries, so we should help those users
• An entire cargo API is orthogonal to assert_cmd and would be best to be stablized outside of assert_cmd

Proposal

• Mirror the concept of cargo run in escargot but via CargoBuild
  • CargoBuild would have a .run() method that would return a CargoRun
  • CargoRun would have .path() and .command() methods.
• Still provide CommandCargoExt but point people to escargot for any custom behavior
• Deprecate the cargo path functions and instead point people to escargot for those use cases.
  • Create an issue for them to be deleted as part of the 1.0 milestone

At this point, CommandCargoExt is primarily serving a low-effort path for a "getting started" user while serving as an example of how to do more complex things (via code) and pointing to more complex APIs (via docs)

Open Issues

• What should be the default for main_binary should reuse the caller's target #4

[epage]

@quininer and @mssun, I've released escargot v0.3.0 with CargoRun support (see docs).

Could you give that a spin to see what you thoughts are? If it works for you, I'll be closing this issue by

• Removing the _path functions from the API (and by extension, removing the cargo mod from the API)
• Updating the docs to point to escargot for advanced use cases (custom builds, caching, etc).

We still need to decide whether the easy-path API should use current_target or not.

[quininer]

I am satisfied with this API, but CargoRun does not seem to work for --example. I got "No binaries in crate".

[mssun]

Thanks @epage, I'm pretty satisfied with the API.

Now I can use

 lazy_static! {
     pub static ref BIN_PATH: PathBuf = escargot::CargoBuild::new()
         .bin("binary_name")
         .current_release()
         .current_target()
         .run()
         .unwrap()
         .path()
         .to_path_buf();
 }

to get the path of binary which compiled with --target xxx.

This works well when test with cargo test --target xxx.

However, when I don't use --target xxx to test (e.g., test the default target: x86_64-unknown-linux-gnu), escargot will still build the binary again and put it into target/x86_64-unknown-linux-gnu/debug instead of target/debug. Seems that escargot cannot detect the existence of the --target flag.

[epage]

@quininer

I am satisfied with this API, but CargoRun does not seem to work for --example. I got "No binaries in crate".

I know exactly whats wrong and will hopefully get a chance to fix it soon. In the mean time, could you open an issue for it on escargot?

@mssun

How come you are caching the path rather than caching the CargoRun and then using BIN.command() to access all the assert_cmd features

However, when I don't use --target xxx to test (e.g., test the default target: x86_64-unknown-linux-gnu), escargot will still build the binary again and put it into target/x86_64-unknown-linux-gnu/debug instead of target/debug. Seems that escargot cannot detect the existence of the --target flag.

It cannot and that is the crux of #4.

[mssun]

It cannot and that is the crux of #4.

Yes, I understand. Thank you. This requires me to run cargo test with --target in any case. But, seems that there is no solution for this.