Response to request

[aklitzke]

Hi!

@sagiegurari you posted here: aklitzke/dors#1 and I'm following up.

I want to start off by saying that I think you've really written a very comprehensive makefile engine that has a ton of features and fits a lot of use cases super well. Thanks for all your hard work on this project, I still use it myself in some projects, and will likely continue to.

I think the honest answer isn't that there are limitations per say in your workspace support, only that we have different ideas about how makefiles should inherit from each other, be structured, and execute within a workspace. I'll detail some of that below:

Lets say we had a basic Makefile.toml:

[tasks.hello]
command = "echo"
args = ["hi"]

1. IMO would be easier if there was just one way of issuing commands, command = "echo hi", instead of multiple.
2. If the makefile is in a workspace, hello will simply fail unless a makefile with a hello task has been explicitly defined for each member in the workspace. This seems odd.
3. If the makefile is in a member crate, hello will run in place. If the makefile is in a workspace root, hello will automatically run against each member. This seems inconsistent.
4. We can create a member makefile and automatically extend the workspace makefile. But, then what if we have tasks that should only be ran at the workspace level?
5. If we want more granular control over what members we run against, the way to do that seems to be to use do-on-members, but its usage with environment variables isn't ideal
6. if we extend the workspace makefile then we can't use a do-on-members task directly from a member.
7. Environment variables defined at the workspace level are not available to members unless they extend the workspace makefile. This seems odd, given that a task defined at the workspace root runs against all members automatically.
8. There are a lot of options configuring stuff like, "where does this makefile extend from", "is this task a 'workspace task' or not", "am I extending from an optional makefile", etc. These make understanding the underlying inheritance model tricky.
9. There could be a task named hello defined behind-the-scenes in cargo-make which is changing the behavior of our task without us knowing.
10. If this is a member makefile, there could be a task named hello defined at the workspace level which is changing the behavior of our task without us knowing.
11. This:

[cargo-make] INFO - makers 0.30.4
[cargo-make] INFO - Build File: Makefile.toml
[cargo-make] INFO - Task: hello
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: workspace
[cargo-make][1] INFO - External file not found or is not a file, skipping.
[cargo-make][1] INFO - Project: member1
[cargo-make][1] INFO - Build File: Makefile.toml
[cargo-make][1] INFO - Task: hello
[cargo-make][1] INFO - Profile: development
[cargo-make][1] ERROR - Task not found: hello
[cargo-make][1] WARN - Build Failed.
[cargo-make] ERROR - Error while executing command, exit code: 1
[cargo-make] WARN - Build Failed.

IMO is too much information in the output

There are other things too, but this covers a lot of it. I think I'll remove the statement about 'limitations in cargo make' from my readme to avoid explicitly calling out this project.

Thanks!

[sagiegurari]

first of all, thanks a lot for your time writing the feedback.
i guess each item in the list is an issue so i'll try to respond to each to see if i'm missing anything...

1. your way is simple. i do see that many projects use the script tag only sometimes because it is simpler to understand and write. however, unless you going to parse that, you wouldn't be able to provide additional added value on top.
2. you mean when running cargo make directly inside a member directory? if so, correct. this is something i should improve. thanks
3. this look like an interesting point but i need more info please. so you mean when running from member dir compared to workspace dir? can you expand on this point please?
4. than those should only be invoked on workspace level. you have conditions to ensure that to be safe and workspace=false to ensure that running this task from cli will run on workspace dir and not on members.
5. good point, i have an idea how to make this one simpler. thanks
6. this one i'm not sure what you mean. why would a member call a task on all members? workspace should talk to members and members should only see themselves. i'm not sure what the flow here is.
7. this is not automatic because i didn't want to do a backward compatibility break. but i agree.
8. agree, too many features and long docs.
9. thats a core concept. there are cli commands to see it. this point i think is a core difference between how we both vision a tool.
10. ya, same as 9 in a way.
11. that is very common item i'm getting feedback on. some say its too much and some say they are missing things. i feel this point will never have a solution that everyone is happy with :(