What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 09:18:26PM +0400, Dmitry Olshansky via Digitalmars-d wrote:
[...]
> I had an "insanely" complicated one could handle 2 platforms, 3
> emulators and a few custom build steps (including signing binaries),
> cleaning, tracking dependencies with minimal rebuilds. For instance,
> binary need not to be signed again if it's bit for bit the same.
> All of the above was done in about 50 lines, never braking as the
> project progressed, I think it changed only 2-3 times over a year.
>
> I was never able to make a good makefile that wouldn't shit on me in
> some way, like not properly cleaning something or handling errors .
> I'm not even talking about the 10+ LOCs for anything barely useful.

+1. Jives with my experience with SCons as well.


> 25-Sep-2014 01:12, Andrei Alexandrescu пишет:
> >(2) any build system for a project of nontrivial size needs a
> >person/team minding it - never saw such a thing as it's just all
> >automated and it works;
> 
> The question is amount of work, size of file and frequency of changes.
> For instance, Scons easily allows not to change a makefile on every
> single added module, I can't say if make could pull it off.

It can. Except that you can expect things will go horribly wrong if you
so much as breathe in the wrong direction. And when you're dealing with
a multi-person project (i.e., 99% of non-trivial software projects),
expect that people will do stupid things that either breaks the
makefile, or they will make breaking changes to the makefile that will
screw everything up for everyone else.


> >(3) especially if the build system is not that familiar, the role of
> >the build czar is all the more important.
> 
> Somebody (Russel?) was working on D Scons support, how about start to
> capitalize on this work? I'd gladly try to make a scons script for
> phobos/druntime if there is even a tiny chance of apporval.

D support has been merged into mainline SCons, thanks to Russel's
efforts. I've been using his D module for a while now, and find it
generally very C/C++-like, which is perfect for projects that need heavy
interfacing between C/C++ and D. For D-only projects, it's a bit klunky
because it defaults to separate compilation, whereas dmd tends to work
better with whole-program compilation (or at least per-module rather
than per-source-file compilation).

SCons does hit performance barriers when you get into very large
projects (on the magnitude of Mozilla Firefox, or the GTK desktop suite,
for example), but for something the size of dmd/druntime/phobos, you
won't notice the difference at all. In fact, you'd save a lot of time by
not needing to make clean; make every single time you do anything
non-trivial.


> >So the reality is quite a bit more complicated than the shiny city on
> >a hill you describe.
> 
> Most people using make/autotools say build systems are hard, it need
> not to be true but I'm obviously biased.
[...]

I'm biased too, but I'm inclined to think that those people say it's
hard because it *is* hard when the best you got is make and autotools.
:-P


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?