A brief survey of build tools, focused on D
Neia Neutuladh
neia at ikeran.org
Thu Dec 13 04:52:12 UTC 2018
On Wednesday, 12 December 2018 at 22:41:50 UTC, H. S. Teoh wrote:
> And here is the crux of my rant about build systems (earlier in
> this thread). There is no *technical reason* why build systems
> should be constricted in this way. Today's landscape of
> specific projects being inextricably tied to a specific build
> system is completely the wrong approach.
You could reduce all this language-specific stuff to a way to
generate a description of what needs to be built and what
programs are suggested for doing it. This is quite a layer of
indirection, and that means more work. "I can do less work" is a
technical reason.
Ensuring that your output is widely usable is also extra work.
There is also a psychological reason: when you're trying to solve
a set of problems and you are good at code, it's easy to tunnel
vision into writing all the code yourself. It can even,
sometimes, be easier to write that new code than to figure out
how to use something that already exists (if you think you can
gloss over a lot of edge cases or support a lot fewer pieces, for
instance).
This is probably why Dub has its own repository instead of using
Maven.
> Seriously, building a lousy software project is essentially
> traversing a DAG of inputs and actions in topological order.
> The algorithms have been known since decades ago, if not
> longer, and there is absolutely no valid reason why we cannot
> import arbitrary sub-DAGs and glue it to the main DAG, and have
> everything work with no additional effort, regardless of where
> said sub-DAGs came from. It's just a bunch of nodes and
> labelled edges, guys! All the rest of the complications and
> build system dependencies and walled gardens are extraneous and
> completely unnecessary baggage imposed upon a straightforward
> DAG topological walk that any CS grad could write in less than
> a day. It's ridiculous.
If any CS grad student could write it in a day, you could say
that having a generic DAG isn't useful or interesting. That makes
it seem pretty much useless to pull that out into a separate
software project, and that's a psychological barrier.
More information about the Digitalmars-d-announce
mailing list