What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

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

-- 
Philosophy: how to make a career out of daydreaming.