Make cargo-build cargo workspace aware

[andrewdavidmackenzie]

Problem

At the moment cargo-build is not aware of cargo workspaces.

So, when it is used in a "member" project of a workspace the target directory is calculated incorrectly, and it does not find the files constructed (e.g. binary) by cargo prior to it running and they cannot be packaged.

Running cargo bundle currently in a member directory of such a project will lead to this output:

cargo bundle
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
    Bundling flowc.app
Error: the source path is not an existing regular file

Proposed Solution

Make cargo-build aware of workspaces.

When it runs, search for cargo workspaces in the parent directories (need to check if that is recursive and multiple levels or not), and parse that Cargo.toml to determine the correct target directory to us.

Need to check for any ways that the standard target directory can be overridden.
According to this issue (rust-lang/cargo#1657) there are at least two:

build.target-dir configuration key
(I'm not sure if that is in Cargo.toml, or any of the .cargo/config files that might apply!)

CARGO_TARGET_DIR=foo; cargo run args

I suspect I might not get all that 100% correct first time, but help fleshing out the correct spec and algorithm for determining what the target directory should be would be appreciated.

[andrewdavidmackenzie]

Looking for spec details:
https://doc.rust-lang.org/cargo/reference/manifest.html#the-workspace-section

Determining if part of workspace, and which:

"The package.workspace manifest key (described above) is used in member crates to
point at a workspace's root crate. If this key is omitted then it is inferred to
be the first crate whose manifest contains [workspace] upwards in the filesystem."

         The Cargo.toml (found walking up the FS) could now have a workspace.exclude entry
         for this crate, meaning that this crate does not below to a workspace.

"Note that members of the workspaces listed explicitly will also have their path
dependencies included in the workspace"

QUESTION: If no workspace root directory is specified by the package.workspace key
do we just look in the parent directory for a Cargo.toml defining a workspace we belong
to, or do we have to walk up the file system until "/" to see if we can find a
Cargo.toml?

[mdsteele]

If I'm understanding cargo's behavior correctly, I think we have to walk all the way up the file system.

[andrewdavidmackenzie]

Yes, it looks like it. Looks like there can be empty directories between current directory and the workspace's root folder....so you need to walk all the way up until you find a Cargo.toml, then you can stop even if it doesn't declare a workspace.

[andrewdavidmackenzie]

See #47

[andrewdavidmackenzie]

@mdsteele any comments on the PR?
Prospects of merging (a cleaned up) version of it?

[andrewdavidmackenzie]

We can close this issue now, no?

A release with support for workspaces would be great now, and then I'd work on the original need to bundle resources from libs....

[mdsteele]

Thanks, I just published v0.3.0 with the latest changes.