On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via
Digitalmars-d wrote:
[...]
If I were to write a build system today that had to spell out
all of
its commands, I'd go with tup or Ninja. That CMake has support
for
Ninja is the icing on the cake for me. I wrote a Ninja build
system
generator the other day, that thing is awesome.
[...]
P.S. I've thought of writing a build system in D, for which the
configuration language would be D. I still might. Right now,
dub is
serving my needs.
I've been thinking of that too! I have in mind a hybrid between
tup and
SCons, integrating the best ideas of both and discarding the
bad parts.
For example, SCons is notoriously bad at scalability: the need
to scan
huge directory structures of large projects when all you want
is to
rebuild a tiny subdirectory, is disappointing. This part should
be
replaced by Tup-style OS file change notifications.
However, Tup requires arcane shell commands to get anything
done --
that's good if you're a Bash guru, but most people are not. For
this, I
find that SCon's architecture of fully-customizable plugins may
work
best: ship the system with prebaked rules for common tasks like
compiling C/C++/D/Java/etc programs, packaging into tarballs /
zips,
etc., and expose a consistent API for users to make their own
rules
where applicable.
If the scripting language is D, that opens up a whole new realm
of
possibilities like using introspection to auto-derive build
dependencies, which would be so cool it'd freeze the sun.
Now throw in things like built-in parallelization ala SCons
(I'm not
sure if tup does that too, I suspect it does),
100%-reproducible builds,
auto-packaging, etc., and we might have a contender for Andrei's
"winner" build system.
P.S.S autotools is the worse GNU project I know of
+100! It's a system of hacks built upon patches to broken
systems built
upon other hacks, a veritable metropolis of cards that will
entirely
collapse at the slightest missing toothpick in your shell
environment /
directory structure / stray object files or makefiles leftover
from
previous builds, thanks to 'make'. It's pretty marvelous for
what it
does -- autoconfigure complex system-dependent parameters for
every
existing flavor of Unix that you've never heard of -- when it
works,
that is. When it doesn't, you're in for days -- no, weeks --
no, months,
of hair-pulling frustration trying to figure out where in the
metropolis
of cards the missing toothpick went. The error messages help --
in the
same way stray hair or disturbed sand helps in a crime
investigation --
if you know how to interpret them. Which ordinary people don't.
T
If you have a passion and interest in this space and would like
to collaborate, I would be thrilled. We can also split this
discussion off of this thread since it is not D specific.
