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

xbuild/cargo: Linearize workspace detection #83

Merged
merged 6 commits into from
Dec 6, 2022
Merged

Conversation

MarijnS95
Copy link
Member

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?

xbuild/src/cargo/manifest.rs Show resolved Hide resolved
Comment on lines 57 to 61
// 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(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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....

Copy link
Member Author

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!

xbuild/src/cargo/mod.rs Outdated Show resolved Hide resolved
xbuild/src/cargo/utils.rs Show resolved Hide resolved
xbuild/src/cargo/mod.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@dvc94ch dvc94ch left a 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!

xbuild/src/cargo/utils.rs Show resolved Hide resolved
xbuild/src/cargo/mod.rs Outdated Show resolved Hide resolved
@dvc94ch
Copy link
Contributor

dvc94ch commented Dec 1, 2022

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?

@MarijnS95
Copy link
Member Author

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 cargo-subcommand and added useful features to it which xbuild lacks, I'm in favour of that (to reduce dual maintenance burden for now). Then we cannot do things like #84 though.

Do you want to pick that up?

@dvc94ch
Copy link
Contributor

dvc94ch commented Dec 1, 2022

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.

@MarijnS95
Copy link
Member Author

MarijnS95 commented Dec 1, 2022

Let's just keep on copy-pasting cargo-subcommand for now then; that only makes converting easier when we make the jump.

@MarijnS95 MarijnS95 force-pushed the workspace-manifest branch 2 times, most recently from 3e13660 to f3f2e0a Compare December 1, 2022 14:04
@dvc94ch
Copy link
Contributor

dvc94ch commented Dec 3, 2022

So merging this?

@MarijnS95
Copy link
Member Author

@dvc94ch no, I first want to fix #83 (comment) both here and in cargo-subcommand. Should be simple but I've yet to come up with an elegant way code-wise. Will be a couple days until I can dedicate time to this though (and subsequently implement workspace inheritance).

MarijnS95 and others added 6 commits December 6, 2022 11:13
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.
Copy link
Contributor

@dvc94ch dvc94ch left a 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?

@MarijnS95
Copy link
Member Author

but distracts from what this crate is actually about, passing the correct flags and env variables to cargo build.

xbuild was already parsing the Cargo.toml manifest before this PR, if you don't want it to maybe we should remove it altogether? It may be used for more nontrivial things than appear on the surface, though. On the other hand, if we keep it, it should at least somewhat mimic what cargo does, correctly.

Note that we also lack [env] support in .cargo/config.toml.

Maybe all this logic can live in a root level crate?

Where would you like/suggest to move this to? xcommon? Or a lean-er variant of cargo-subcommand so that I didn't have to transplant (and now maintain) the same code in two spots?

@MarijnS95 MarijnS95 merged commit d5ff1af into master Dec 6, 2022
@MarijnS95 MarijnS95 deleted the workspace-manifest branch December 6, 2022 17:24
@dvc94ch
Copy link
Contributor

dvc94ch commented Dec 6, 2022

no, xcommon was intended for utilities used across various file formats, this should not live in xcommon. just add a new top level crate, xbuild-cargo or whatever. yes it would be a leaner version of cargo-subcommand.

@dvc94ch
Copy link
Contributor

dvc94ch commented Dec 6, 2022

actually, ideally we'd get rid of xcommon, not sure if it's even needed

@MarijnS95
Copy link
Member Author

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.

@dvc94ch
Copy link
Contributor

dvc94ch commented Dec 6, 2022

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:

use xcommon::{Scaler, ScalerOptsBuilder, Signer, Zip, ZipFileOptions, ZipInfo};

@dvc94ch
Copy link
Contributor

dvc94ch commented Dec 6, 2022

why the llvm stuff is in there I don't really know

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