4 ms·

Haven't checked ninja, but I've blogged a bit on limitations in common build systems, such as make and its various derivatives: "The problem with make for scie

by samuell 10y ago

Haven't checked ninja, but I've blogged a bit on limitations in common build systems, such as make and its various derivatives: "The problem with make for scientific workflows": http://bionics.it/posts/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 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.

dmytroi 10y ago
From the first blog post: > 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. - [1] https://github.com/beardsvibe/buildfox/ https://github.com/beardsvibe/buildfox/