This is what we should be working on:

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED 

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 10/1/2013 1:32 PM, Walter Bright wrote:
> This is what we should be working on:
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED 
>


Or compiler crashes:

http://d.puremagic.com/issues/buglist.cgi?keywords=ice&query_format=advanced&keywords_type=allwords&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

The quantity of these is embarrassing. Nothing makes dmd look worse than crashing.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Tue, 01 Oct 2013 13:32:00 -0700
Walter Bright <walter@digitalmars.com> wrote:

> This is what we should be working on:
> 
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
> 

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.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

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?
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Oct 02, 2013, at 07:37 AM, Walter Bright <walter@digitalmars.com> wrote:

> 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 would assume Nick's work is a prerequisite for automatically building release packages.

--
/Jacob Carlborg

On Tue, 01 Oct 2013 22:37:17 -0700
Walter Bright <walter@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.)
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 10/2/13 1:45 AM, Nick Sabalausky wrote:
> On Tue, 01 Oct 2013 22:37:17 -0700
> Walter Bright <walter@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

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

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

On 10/03/2013 06:47 AM, Brad Roberts wrote:
> 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. 
That sounds like the way to go, how feasible is it to do this before this release?
Especially considering that there are some dreaded dependencies on external binary
not in the git repo.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 10/13/13 8:38 PM, Martin Nowak wrote:
> On 10/03/2013 06:47 AM, Brad Roberts wrote:
>> 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.
> That sounds like the way to go, how feasible is it to do this before this release?
> Especially considering that there are some dreaded dependencies on external binary
> not in the git repo.

I believe this sort of process disruption is better doing during the development phase of a release and not during the finalization of a release.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta