prefer creating changelog verbatim from _pre.dd

[MartinNowak]

• see 9ed394e

[CyberShadow]

Typo in commit message, verbatiom

[MartinNowak]

In fact this seems to solve all problems w/ changelog gen nicely, once there is a checked-in _pre.dd file, the changed tool will no longer be invoked, allowing us to "freeze" the changelog. One a version is out, we'll bump VERSION and have changelog previews again.
A bit too complex for my taste, but should work.

[MartinNowak]

Typo in commit message, verbatiom

thx, fixed :)

[MartinNowak]

I still have an issue w/ the doc gen for ddmd_mars.html, b/c it imports ddmd.objc which fails to compile on non-OSX machines. The hacky default is to abuse D's module != filename mechanism and pass ddmd/objc_stub.d to the compiler, so that it'll import that one instead of ddmd/objc.d :/.

Just wondering why that doesn't happen with Digger.

[MartinNowak]

Just wondering why that doesn't happen with Digger.

Because of -O -release -inline, the release uses RELEASE=1 to enable optimizations.

[MartinNowak]

There are 2 long-term conflicts between dlang.org's Makefile and the release build script, since dlang.org turned into it's own build-the-world system.

One recurring problem is that dlang.org always tries to build sth. that's already taken care of the other build system. While it sounds simple to refactor the makefile in such a way to have a dlang.org only target, it's fairly tricky due make's nature of declaring dependencies and build targets.

order-only prerequisites work to some extend but seem somewhat fragile (at least noone thinks of using them).

The other problem is that the release build needs to use the pre-release targets (and only those) to builds a release documentation. At the time the docs are build, no binaries/tags are published, so we can't use the normal release target.
I hope this will become less tricky with the switch to dpl-docs, but to get rid of the dlang.org patch in the release script we'd need to introduce a third target I guess.