main_binary should reuse the caller's target

[epage]

I suspect when running cargo test --target TRIPLET that main_binary will still use the default TRIPLE.

Downside: when the user is calling cargo test without a --target, assert_cmd passing --target will cause a one-time large compile time cost

See assert-rs/assert_cli#109

[epage]

See assert-rs/assert_cli#102

[epage]

From #43

@mssun

As described mesalock-linux/mesabox#41. I don't know why the first tests are always blocking for over 60 seconds. However, after the blocking issue, all testcases can be run without any problem.

test gnu::arch::test_x86_64 ... test gnu::arch::test_x86_64 has been running for over 60 seconds
test gnu::base32::test_decode ... test gnu::base32::test_decode has been running for over 60 seconds

This only happens in Travis: https://travis-ci.org/mesalock-linux/mesabox/jobs/411140601#L1305

I cannot reproduce this issue in my machine. Don't know why.

@epage

You are having the opposite problem of me with #4.

Your tests build with --target but assert_cmd doesn't. Even if they are the same target, cargo will do a unique build for it, blocking your tests. I'm guessing its two tests because they are running in parallel and one is being blocked on the other having the file lock.

This is a tricky situation. Ideally, we'd always pass along --target but for the default case, it'll slow people's tests down.

Options

• An API but like Allow CommandCargoExt to pass build arguments #34 there are complications with letting people customize the behavior
• A feature flag to opt-in.
• ... something else?

@mssun

Yes, this is the problem. Testing with cargo test does not have this issue, but cargo test --target x86_64-unknown-linux-musl still has.

cargo test:

• https://travis-ci.org/mesalock-linux/mesabox/jobs/411409632#L996
• https://travis-ci.org/mesalock-linux/mesabox/jobs/411409632#L1696

cargo test --target x86_64-unknown-linux-musl

• https://travis-ci.org/mesalock-linux/mesabox/jobs/411409633#L1013
• https://travis-ci.org/mesalock-linux/mesabox/jobs/411409633#L1425

This is a tricky situation. Ideally, we'd always pass along --target but for the default case, it'll slow people's tests down.

I'm not quite understand the tricky situation, and how it affects the cargo test --target x86_64-unknown-linux-musl case. Do you mean that no matter what target I pass to the cargo, assert_cmd will do a build for me (and without any target flag)?

Anyway, for the solution, I prefer to a esay/intuitive one like a feature flag to opt-in.

[epage]

Do you mean that no matter what target I pass to the cargo, assert_cmd will do a build for me (and without any target flag)?

As of right now, yes.

• If we start passing in --target, we hurt the performance of those who don't pass in --target.
• But without it, we hurt your performance and reduce your platform coverage

[epage]

I've started mapping out what we might due to the API to help

Please check out #44 and provide feedback