use the manifest path instead of just the member name when using prepare --bin
#255
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #, if available:
Closes: #232
Description of changes:
The current code assumes that when running
prepare
with--bin
, that we can remove all members and just add one member that is equal to whatever we passed in--bin
.The problem with that is that if your packages aren't in the exact same root directory, then this will result in a recipe file that breaks once you try calling
cook
on it.To fix this, this PR instead sets the sole member to the path of the package, which (I think) can be found using in
cargo_metadata::Metadata
, grabbing the manifest path, and setting it to be relative to the workspace root + removingCargo.toml
from the path. I chose to do it this way rather than just matching + grabbing whatever's in themembers
array as I don't think that would work due to wildcards being valid.This also adds a test emulating various package locations in a workspace and seeing if the path is correctly set. This previously failed, but now passes with these changes. All other previously-existing tests seem to pass, so I don't believe this should break things. That said, if people were using the workaround mentioned in #232, then I believe this will be a breaking change, so that'll probably have to be communicated.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.