Propose syntax-sugar for referring to tasks in other crates

[arlyon]

I have a workspace with many crates. As part of the packaging process, I'd like to copy some files (html templates) between them. This copy stage depends on some preprocessing defined in src/web/Makefile.toml. In the root Makefile.toml I am having to create a dummy task that changes directory and runs the target I want.

src/web/Makefile.toml

[tasks.yarn]
command = "yarn"

[tasks.css]
command = "yarn"
args = ["build"]
dependencies = ["yarn"]

[tasks.dist]
command = "cp"
args = ["-a", "static/.", "dist/"]
dependencies = ["css"]

Makefile.toml

[tasks.web-dist]
cwd = "src/web"
command = "cargo"
args = ["make", "dist"]

[tasks.web-release]
cwd = "src"
command = "cp"
args = ["-r", "web/dist", "application/dist"]
dependencies = ["web-dist"]

The combined result of which is:

• compile the css
• copy it into dist along with the static files
• copy the files into the application crate

My question: there is a little boilerplate task here, would it be an idea to provide some sugar and allow me to define a dependency as follows instead?:

[tasks.web-release]
cwd = "src"
command = "cp"
args = ["-r", "web/dist", "application/dist"]
dependencies = ["web:dist"]

web:dist could either be a path or a crate in the workspace, and it refers to the dist task inside the Makefile there.

[sagiegurari]

Interesting idea.
What if it was an object instead?

dependencies  = [ { cwd = "src/web", name = "dist", fork = true }, { name = "some-local-task" } ]

which would trigger a sub cargo make process (as you did manually)?
The fork would always be true, but if i'm making it an object now, i need to think of future support for other things.
does it make sense?

[arlyon]

Yeah that could work, while making "some-local-task" and { name = "some-local-task" } equal. If you give some pointers I'd be happy to take a crack at it once we think about it a little more.

[sagiegurari]

@arlyon if you want create a PR (always happy to get help) here are the pointers i can give:

• types.rs - update the task and platform task structs to have dependencies instead of vec of strings, a vec of enum of either string or a new type that can have those fields. I do stuff like that a LOT in that file so you have many examples.
• execution_plan.rs - when you loop over dependencies, if you come up with a fork one, create a task in runtime instead of pulling a task from the read toml file. give the task some name like 'forked_dependency' or something....
  that runtime created task should have command->cargo args->make, all needed stuff, task name from obj, cwd-> from obj
  i have create_proxy_task or something in the runner.js that can be used... it knows to automatically put in the command line all the needed args that you put in the original invocation. which is very important.
• tests
• examples
• docs - content.md/nav.md as readme.md is generated from those via cargo make generate-docs

if you feel its too much, its ok. just tell me and i'll take it.

[arlyon]

Cool, I had a go at the first bit. Expect a PR soon :)

[sagiegurari]

@arlyon i was manually testing this one and i found a bug there when the path specifies a file name as well (i was actually testing the cross-file.toml you created).
I think the issue is that you take the full path as directory path and do not split the filename from it

let mut proxy_task = create_proxy_task(&proxy_name, true, false);
proxy_task.cwd = Some(path.to_owned());

what i think you wanted to do is check that path and than if its a dir than ok, if its a file to break it down to path to put in cwd and filename to put in the cargo make args list.

would you like to take care of it or should I fix it?

[sagiegurari]

i would also add a test for both scenarios to make sure the generated proxy task is as we wanted it to be.

[arlyon]

Hey! Yes it seems I missed that case, I thought that that was covered since the example I wrote worked but that was in the same directory. I'll get a patch up asap

[sagiegurari]

@arlyon are you taking care of this one or you prefer me to fix it?

[arlyon]

Hey, I've been working on this but its a bit more complex than I had initially thought regarding paths and things.

[sagiegurari]

i can take a look as well.

[arlyon]

Yes, that would be helpful. This next few days are quite busy with work wrapping up before the holidays and I understand it's kind-of time sensitive. Thank you (and sorry)!

[sagiegurari]

@arlyon fixed it. you can look at the relevant commit if you are interested.

[sagiegurari]

released