What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 07:19:14PM +0000, Cliff via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 18:51:13 UTC, H. S. Teoh via
> Digitalmars-d wrote:
> >You don't know if recompiling after checking out a previous release
> >of your code will actually give you the same binaries that you
> >shipped 2 months ago.
> 
> To be clear, even if nothing changed, re-running the build may
> produce different output.  This is actually a really hard problem
> - some build tools actually use entropy when producing their
> outputs, and as a result running the exact same tool with the
> same parameters in the same [apparent] environment will produce a
> subtly different output.  This may be intended (address
> randomization) or semi-unintentional (generating a unique GUID
> inside a PDB so the debugger can validate the symbols match the
> binaries.)  Virtually no build system in use can guarantee the
> above in all cases, so you end up making trade-offs - and if you
> don't really understand those tradeoffs, you won't trust your
> build system.

Good point.


> What else may mess up the perfection of repeatability of your
> builds?  Environment variables, the registry (on Windows), any
> source of entropy (the PRNG, the system clock/counters, any
> network access), etc.

Well, obviously if your build process involves input from output, then
it's impossible to have 100% repeatable builds. But at least we can do
it (and arguably *should* do it) when there are no outside outputs.

I actually have some experience in this area, because part of the
website project I described in another post involves running gnuplot to
plot statistics of a certain file by connecting to an SVN repository and
parsing its history log. Since the SVN repo is not part of the website
repo, obviously the build of a previous revision of the website will
never be 100% repeatable -- it will always generate the plot for the
latest history rather than what it would've looked like at the time of
the previous revision. But for the most part, this doesn't matter.

I *did* find that imagemagick was messing up my SCons scripts because it
would always insert timestamped metadata into the generated image files,
which caused SCons to always see the files as changed and trigger
redundant rebuilds. This is also an example of where sometimes you do
need to override the build system's default mechanisms to tell it to
chill out and not rebuild that target every time. I believe SCons lets
you do this, though I solved the problem another way -- by passing
options to imagemagick to suppress said metadata.

Nevertheless, I'd say that overall, builds should be reproducible by
default, and the user should tell the build system when it doesn't have
to be -- rather than the other way round. Just like D's motto of safety
first, unsafe if you ask for it.


[...]
> Different people will make different tradeoffs, and I am not here
> to tell Andrei or Walter that they *need* a new build system for
> D to get their work done - they don't right now.  I'm more
> interested in figuring out how to provide a platform to realize
> the benefits for build like we have for our modern languages, and
> then leveraging that in new ways (like better sharing between the
> compiler, debugger, IDEs, test and packaging.)

Agreed. I'm not saying we *must* replace the makefiles in dmd / druntime
/ phobos... I'm speaking more categorically, that build systems in
general have advanced beyond the days of make, and it's high time people
started learning about them. While you *could* write an entire
application in assembly language (I did), times have moved on, and we
now have far more suitable tools for the job.


T

-- 
"Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra