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

[Brad Roberts]

On 10/2/13 1:45 AM, Nick Sabalausky wrote:
> On Tue, 01 Oct 2013 22:37:17 -0700
> Walter Bright <walter at digitalmars.com> wrote:
>
>>
>> On 10/1/2013 8:04 PM, Nick Sabalausky wrote:
>>> On a related note (in case it hasn't been noticed), the release
>>> generator tool should be usable now:
>>>
>>> https://github.com/D-Programming-Language/installer/pull/24
>>>
>>> Aside from doing zip, 7z, OS-specific and all-OS releases, it should
>>> also significantly reduce the risk of manual mistakes/oversights
>>> like forgetting to rebuild tool X on OS Y, or included sources not
>>> matching github, etc.
>>> _______________________________________________
>>>
>>
>> Thank you.
>>
>> I want to get to the point where the auto-tester automatically (and
>> continuously) builds release packages. Does this fit in with that?
>
> I don't know much about the autotester (whoever manages that would
> need to chime in here). But AIUI, yes, it should fit into that very
> well. In fact, that would probably be an ideal way to drive this tool.
>
> All the autotester should need to do is invoke create_dmd_release
> tool (just one command) on each platform and all the platform-specific
> zip and 7z releases should be good to go.
>
> Then, for the "all OSes" release, all the os-specific releases need to
> be put in a common directory on a posix machine (I don't know how the
> autotester would do that though, I would guess it wouldn't be too hard),
> and then again it's just one more command.
>
> The top of the tool's source file explains typical expected usage:
>
> https://github.com/Abscissa/installer/blob/create_dmd_release/create_dmd_release/create_dmd_release.d
>
> And there's a --help screen explaining all the options. (Speaking of
> which, getopt() is awesome.)

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), 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).

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.

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.

My 2 cents,
Brad