Idea: std.build instead of dub and make-like tools

[H. S. Teoh via Digitalmars-d]

On Thu, Mar 17, 2016 at 05:25:32AM +0000, Piotrek via Digitalmars-d wrote:
> On Wednesday, 16 March 2016 at 18:36:48 UTC, Mark Isaacson wrote:
> >From experience, it turns out that having a restricted language to
> >specify your builds/dependencies is a very good thing. You really
> >don't really want a turning complete language for this; it just makes
> >it harder to reason about.
> 
> I agree that everybody has different experience. My, for example, is
> opposite.
> 
> 1. Make and derivatives are unintuitive to use and lead to
> unmaintained mess.
> 2. Simple and descriptive formats like JSON means neverending demand
> for extension and alternatives (dub situation).
[...]

Personally, I also find makefiles have a tendency to become unmaintable
messes. I have yet to find one non-trivial project whose makefiles
*aren't* unmaintainable messes.  The dmd toolchain tries to, but fails
(esp. with the nasty cross-repo references that will basically fail in
ugly ways in every case except when you setup your environment exactly
like the makefiles implicitly assume -- the hallmark of design smell).

My current go-to build system is SCons, a Python-based build system
where build scripts are Python scripts. However, far from becoming a
problem due to Turing-completeness, generally I hardly ever use the full
expressive power of Python; the primitives provided take care of 99% of
the most typical build scenarios. However, for those rare but
unavoidable cases where you need something more, having a full
programming language at your disposal is a life-saver. When the
primitives provided by SCons can't quite express what you want, you can
code the desired result by hand, and it integrates smoothly into the
rest of the system. No need to plead for extensions and Yet More
Complicated Conditional Clauses to handle your particular corner case,
and potentially being forced to wait a whole release cycle to get what
you need.

I think a good balance can be drawn between providing enough primitives
that cover almost all conceivable use cases in a build tool, and at the
same time provide an "escape hatch" into a full-fledged programming
language for those rare but inevitable cases where you need to go
outside the box and do what the designers didn't anticipate.

(Note that while SCons is pretty good in my book, it isn't perfect, and
its dependency management algorithms are somewhat dated.  Newer than
makefiles, for sure, but not quite up to the standard of new, scalable
build tools like tup, whose running time depends on changeset size, as
opposed to repo size -- very important for minimizing the
code-test-debug cycle times.)


T

-- 
If blunt statements had a point, they wouldn't be blunt...