Recursively descend into crates NOT in workspace?

[connorkuehl]

Is there any way to set up a root-level Makefile such that 'cargo make' can be ran at the root folder and it will descend into other folders which contain crates?

We specifically cannot use cargo workspaces due to how cargo coalesces features which complicates things for us when we have a number of crates that are using the same dependency like libc in no_std and std modes.

For example, our repository looks something like this:

enarx
├── Makefile.toml
├── cc
├── CONTRIBUTING.md
├── crt0stack
├── deny.toml
├── docs
├── enarx-keep-sgx
├── enarx-keep-sgx-shim
├── enumerate
├── intel-types

I'd like to be able to just run 'cargo make build' or some other target at the top level and have 'cargo make' descend into these crates and execute the target.

[sagiegurari]

interesting problem. let me think of how i can set a 'workspace' mode without a real workspace.

[sagiegurari]

@connorkuehl this is now implemented in the 0.30.6 development branch.
you can install from there and give it a try.
would like to get feedback from you to see that it works well in your scenario.

The docs to set it up:
https://github.com/sagiegurari/cargo-make/tree/0.30.6#usage-workspace-emulation

basically:

[env]
# this is optional of course...
CARGO_MAKE_EXTEND_WORKSPACE_MAKEFILE = "true"

# this tells cargo-make that this directory acts as a workspace root
CARGO_MAKE_WORKSPACE_EMULATION = true

# a list of crate members. since we do not have a Cargo.toml, we will need to specify this in here.
CARGO_MAKE_CRATE_WORKSPACE_MEMBERS = "member1;member2"

[connorkuehl]

Hi @sagiegurari! Wow! That was quick. It seems to work well! I can't speak to some of the more advanced configurations because for our purposes we are mainly just building, testing, running clippy, rustfmt, etc.

I don't think Cargo workspaces do this, but do you think that cargo make could recurse deeper than just 1 layer? Here's an example of the structure I'm talking about. In this example, one could run cargo make at the root and cargo make would descend into bin which the Makefile there instructs it to descend into my-crate. Similarly: cargo make in the root -> cargo make in lib/ -> runs target across the members my-lib and my-other-lib.

I think that might allow for some interesting flexibility with 'cargo make'. I was able to accomplish an overall build with that same directory structure by just using the full filepaths for members of course. Example of that. I'd be happy to help in any way I can with this.

Also, is there any way to list the members for the environment variable on their own separate lines? the CARGO_MAKE_CRATE_WORKSPACE_MEMBERS list can get very long and wraps quite a bit for a bigger repo. When I tried to do this with backslashes I get a panic

[sagiegurari]

• are you sure you really want more than 1 level?
  the 'rust' way of doing it is what you did in your example: bin/my-crate;lib/my-lib;lib/my-other-lib which seems pretty correct to me.
  Adding makefiles in the middle kinda makes things more complex i think and is not consistent with rust workspaces.

• multi line - you could do that with duckscript i think (didn't test):

env_scripts = [
'''
#!@duckscript
handle = array()
array_push ${handle} member1
array_push ${handle} member2
array_push ${handle} member3
array_push ${handle} member4

members = array_join ${handle} ;

set_env CARGO_MAKE_CRATE_WORKSPACE_MEMBERS ${members}
'''
]

[connorkuehl]

are you sure you really want more than 1 level? the 'rust' way of doing it is what you did in your example: bin/my-crate;lib/my-lib;lib/my-other-lib which seems pretty correct to me.

That's fair. We're just trying to think of ways to organize our repo.

Thanks for the great work on this!

[haraldh]

* are you sure you really want more than 1 level?
  the 'rust' way of doing it is what you did in your example: `bin/my-crate;lib/my-lib;lib/my-other-lib` which seems pretty correct to me.
  Adding makefiles in the middle kinda makes things more complex i think and is not consistent with rust workspaces.

* multi line - you could do that with [duckscript](https://github.com/sagiegurari/duckscript) i think (didn't test):

env_scripts = [
'''
#!@duckscript
handle = array()
array_push ${handle} member1
array_push ${handle} member2
array_push ${handle} member3
array_push ${handle} member4

members = array_join ${handle} ;

set_env CARGO_MAKE_CRATE_WORKSPACE_MEMBERS ${members}
'''
]

shouldn't this be an array instead of a ; separated string in the first place?

[sagiegurari]

that's good feedback.
currently i don't support
env = [...]
but maybe i should as long as people understand that it will be converted to a ; delimited string

[sagiegurari]

just thought, the question is why the var is string and not an array type, and not how to define it.

so those variables are basically environment variables. as such its a map<string,string> structure.

[sagiegurari]

@connorkuehl @haraldh based on your feedback, i now support arrays, so it can be more easily defined as follows:

CARGO_MAKE_CRATE_WORKSPACE_MEMBERS = [
    "member1",
    "member2"
]

[sagiegurari]

both features have been released in 0.30.6 version.
thanks a lot for the ideas.