[dmd-beta] getting ready for beta - but we have lots of regressions

[Nick Sabalausky]

On Wed, 02 Oct 2013 21:47:16 -0700
Brad Roberts <braddr at puremagic.com> wrote:
> 
> IMHO, what create_dmd_release does is fine for end users, but isn't a
> good fit for the auto-tester or automated build/test/release.  It's
> performing redundant work in some areas (like clone and build),

The auto-cloning is optional, see --use-clone=<path>

The building needs to be done because how can you do automated
packaging *reliably* without having control over how the makefiles get
invoked?

> and
> working around limitations that need to be addressed directly, like
> including files that aren't currently source available and part of
> the build process (like dumpobj, etc).

create_dmd_release does nothing to prevent such things from getting
fixed. That's almost completely orthogonal, except in that this at
least allows us to better deal with the issue in the meantime.

> 
> I really want the various package makefiles to have a target that
> constructs a directory of the results of the build that are suitable
> for directly being bundled up into a release.
> 

The last thing we need is to be increasing our usage of
platform-specific and repo-specific makefiles. Our ten or so
makefiles are already horribly inconsistent with each other (both
"Posix vs Win32 vs Win64" and "DMD vs Druntime vs Phobos vs dlang.org
vs tools"[1]). Sticking more functionality into them will only give
(g|dm)make more bits to rot.

[1] create_dmd_release has gone to great pains to spell its
make invocations so they do more-or-less the same thing on each
platform. And even at that, several makefile fixes were still needed.
Yes, this does mean the makefiles need to be improved *regardless* of
create_dmd_release, but it also demonstrates make's natural tendency to
breed bitrot.

> ie, create_dmd_release works around problems that I believe should be
> addressed at the root and I'd rather live with a less than ideal
> auto-tester produced output as a forcing function for getting a more
> correct more direct solution in place.
> 

I have no problem with replacing create_dmd_release with something
better, and I agree that certain things should still be addressed
outside create_dmd_release (which would simplify create_dmd_release's
implementation anyway).

But I definitely have a problem with sacrificing ready-to-go
improvement for the sake of an "even better" improvement that doesn't
actually exist, and may-or-may-not exist in the future. (How long ago
was it we decided to nix assertPred in favor of "easy" assert
improvements that never materialized?)

Unless there are real practical or fundamental problems with
create_dmd_release, it would be silly not to make use of it. Then,
**when and if** deeper improvements render create_dmd_release obsolete,
that's all the better; we can abandon it *at that point* without having
to needlessly sacrifice the benefits it offers in the meantime.