-
-
Notifications
You must be signed in to change notification settings - Fork 42
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
xbuild/cargo: Linearize workspace detection #83
Conversation
xbuild/src/cargo/mod.rs
Outdated
// If a workspace was found, and the user chose a package with `-p`, find packages relative to it | ||
// TODO: What if we call `cargo apk run` in the workspace root, and detect a workspace? It should | ||
// then use the `[package]` defined in the workspace (will be found below, though, but currently | ||
// fails with UnexpectedWorkspace) | ||
utils::find_package_manifest_in_workspace( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most notably this TODO: rust-mobile/cargo-subcommand#25 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dvc94ch before re-approving: this is the only thing that really needs to be looked into....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dvc94ch I ended up implementing this (and some more fixes) in rust-mobile/cargo-subcommand#25, can you please take a look at the last 3 commits? If you are okay with that approach I'll transplant the changes to xbuild
!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me, thanks!
I vaguely recall that at one point we agreed xbuild would use cargo-subcommand or a variation of it, but then the work was never done. what are your thoughts? |
Must be long enough ago that I don't remember, but since I have been maintaining Do you want to pick that up? |
It's not really a priority for me right now as the minimum subset of cargo that xbuild implements works just well enough for my purposes. But I'm open to a PR. |
fd76efb
to
03edef6
Compare
Let's just keep on copy-pasting |
3e13660
to
f3f2e0a
Compare
So merging this? |
@dvc94ch no, I first want to fix #83 (comment) both here and in |
When calling `.parent()` on a filename the result is `""`, which should be treated as PWD (`"."`) but `dunce::canonicalize()` ends up in a "No such file or directory".
`.ancestors()` only calls `.parent()` on a `Path` which walks up until the string empty, but this isn't the root of the filesystem if the path wasn't absolute.
Instead of relying on non-workspace logic.
f3f2e0a
to
60e43e5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is fine. but distracts from what this crate is actually about, passing the correct flags and env variables to cargo build. Maybe all this logic can live in a root level crate?
Note that we also lack
Where would you like/suggest to move this to? |
no, |
actually, ideally we'd get rid of xcommon, not sure if it's even needed |
Fine by me, I haven't really seen the need for a split there. Having it more modularized would definitely benefit us and external parties. |
so the reason for xcommon is for providing these utilities used by the appbundle, apk and msix crates related to image processing, zip files and signing:
|
why the llvm stuff is in there I don't really know |
Import cargo workspace changes from cargo-subcommand in preparation for workspace inheritance.
This effectively synchronizes us with:
rust-mobile/cargo-subcommand#23
rust-mobile/cargo-subcommand#24
rust-mobile/cargo-subcommand#25
(and a tiny initial bit of rust-mobile/cargo-subcommand#12)
@dvc94ch the changes from rust-mobile/cargo-subcommand#25 are still WIP, would you mind checking them out with me (see TODOs) and deciding where to go next?