Seems like a lot of work to setup. Also, spent several minutes on the docs, and did not one line of code; examples?
https://github.com/common-workflow-language/workflows/tree/m...
Anything beyond that trivial example Makefile will rather the reflect the system and environment on which it was written.
- [1] https://ninja-build.org/ - [2] https://travis-ci.org/ - [3] https://www.incredibuild.com/ - [4] http://fastbuild.org/ - [5] https://github.com/distcc/distcc
"The problem with make for scientific workflows":
http://bionics.it/posts/the-problem-with-make-for-scientific...
"Workflow tool makers: Allow defining data flow, not just task dependencies"
http://bionics.it/posts/workflows-dataflow-not-task-deps
The last of which is a limitation of even the most of the "very much-engineered" ones, as the post goes on to explain.
> Files are represented by strings
I think it's especially true for make - looks like it was designed to efficiently express operations for transformations of the same type (like .cpp -> .o/.obj). So in different use case it may become a bit clumsy to use. Ninja should help a bit in this case - you can define a rule, and just use rule name when defining inputs and outputs of a build statement, though it still operates on files.
>[Problems with] combinatorial dependencies
Yes, partially this could be fixed with wildcards in make. Ninja doesn't have wildcard support, so I've created the buildfox [1] to fix it :)
>Non-representable dependency structures
I think it's a limitation of this type of build systems, their configuration language oriented on expressing "how" to achieve things, not "what" to achieve.