On Wed, 02 Oct 2013 21:47:16 -0700 Brad Roberts <[email protected]> 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. _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
