https://github.com/common-workflow-language/workflows/tree/m...
https://github.com/common-workflow-language/workflows/tree/m...
- [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.
Anything beyond that trivial example Makefile will rather the reflect the system and environment on which it was written.