On 3/23/14, 3:44 PM, Iain Buclaw wrote:
On 23 March 2014 21:58, Brad Roberts <bra...@puremagic.com> wrote:
I'm not at all concerned about space, and not sure why most developers would
be. Assuming that the GDC changes were done on a non-master branch, and
that master reflects the GCC master, then seeing what the GDC changes are
would be a typical git operation: git diff master..GDC.
But I can deal with a json config file if necessary. Even better / easier,
would be a file with a single line that is the name of the file that should
exist, ie:
-----
gcc-4.9-20131201.tar.bz2
-----
I don't mind updating the tester as it stands today, but I kinda need to
_know_ it needs to be updated. Waiting for things to fail, waiting for
someone to notice, and waiting for someone to diagnose it as being 'too old'
all sucks. :)
I'll try to remember to update the snapshot version each time I rebase
my GCC sources. ;)
If the GDC repo contained 3 branches, GDC-4.7, GDC-4.8, and GDC-4.9, having
the auto-tester work on them would be _trivial_. I could enable that right
now. It takes less than 5 minutes to do for new DMD branches.
https://github.com/D-Programming-GDC/GDC/branches
master is synonymous with GDC-4.9
I was referring back to having the repository be complete, not just the delta on top of gcc. As
deltas it's no longer a "checkout and build" process. Not hard steps, to be sure, but more steps
that are gdc build process specific.
