Skip to content
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

Add ability to run bin and example from other crates in workspaces #67

Closed

Conversation

AnderEnder
Copy link
Contributor

This option adds an ability to run targets from different packages/crates in workspaces.

Workspaces contain several crates and it is a common situation when integration tests are located in a separate crate.

There is an open question for naming: crate(used in general description) vs package (used in cargo). I selected package in escargot, because it represents cargo arguments, but use crate here, because it is a general term: crates in workspaces.

@epage
Copy link
Contributor

epage commented Jan 6, 2019

This is forcing me in making a decision I've been procastinating.

Right now, we have a tension between #4 and #57. matklad's proposal resolves that tension but it would make cargo_bin function differently than main_binary and cargo_example such that I'm considering removing them all and telling people to use escargot if the want something besides cargo_bin.

@AnderEnder
Copy link
Contributor Author

AnderEnder commented Jan 6, 2019

@epage,
This PR is a first and simplest solution for me.

But I have another proposal and related changes to inject escargot cargo builder into the current behaviour, which allows to control all escargot options: #68

Regarding matklad's proposal, it only works if binaries are already built, but this is not right for workspaces: cargo test can be run in one crate directory, so only direct crate dependencies will be built, while others could be empty or outdated. In this case escargot features can assure that all required bins are fresh and built.

@epage
Copy link
Contributor

epage commented Jan 29, 2019

Closing in favor of #69

@epage epage closed this Jan 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants