On Monday, 12 June 2017 at 06:38:34 UTC, ketmar wrote:
Sebastien Alaiwan wrote:
The selling points, to me, are:
1) the automatic dependency detection through filesystem hooks
2) recipes also are dependencies
3) the genericity/low-level. I believe build systems should
let me define my own abstractions, instead of trying to define
for me what an "executable" or a "static library" should be.
i'm not that all excited by "1", though. tbh, i prefer simplier
things, like regexp scanning. while regexp scanners may find
more dependencies than there really are, they doesn't require
any dirty tricks to work.
I understand your point ; I was explaining to my colleagues
yesterday that "1" was a "good step in the wrong direction".
I think dependencies should come from above, they should be
forced at the build system level. No more 'include' or 'imports'
(Bazel took one step into this direction).
The consequence is that now you can't consider the build system
of your project as a second class citizen. It's the only place
where you're forced to express something vaguely resembling to a
high-level architecture.
Instead of letting module implementations happily create
dependencies to any other module implementation (which is an
architectural sin!) and then resorting to system-level hacks to
try to re-create the DAG of this mess (and good luck with
generated files).
However: "1" is still a "good" step. Compared to where we are
now, it's in theory equivalent to perfectly doing regexp/gcc-MM
scanning, in a langage agnostic way. It's a net win!
