Am Sun, 23 Mar 2014 14:58:01 -0700
schrieb Brad Roberts <braddr@puremagic.com>:

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

It's not really space, it's the time needed for a git clone. Cloning gdc already takes 12 min here. Cloning the gcc repo takes 4 hours and 50 min. I end up cloning gdc more often than I like (testing build scripts, testing gdc on new machines, ...)

Also linux distributions want to use GDC with the same GCC version they normally use. So if a distribution uses gcc-4.8.1 but our sources are gcc-4.8.2 only that'd be a problem. The current approach always works for all minor versions.

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

OK, I've added a gcc.version file to all branches. It's the name of the source archive without the 'tar.bz2' file extension. https://github.com/D-Programming-GDC/GDC/blob/master/gcc.version https://github.com/D-Programming-GDC/GDC/blob/gdc-4.8/gcc.version https://github.com/D-Programming-GDC/GDC/blob/gdc-4.7/gcc.version

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

On 24 March 2014 08:27, Johannes Pfau <nospam@example.com> wrote:
> Am Sun, 23 Mar 2014 14:58:01 -0700
> schrieb Brad Roberts <braddr@puremagic.com>:
>
>> 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.
>
> It's not really space, it's the time needed for a git clone. Cloning gdc already takes 12 min here. Cloning the gcc repo takes 4 hours and 50 min. I end up cloning gdc more often than I like (testing build scripts, testing gdc on new machines, ...)
>

If it's taking that long, you can just switch to git+ssh cloning. That's what I did when I push up my gdb mirror (took about 3 hours for the initial push after endless timeout+retries with http).


> Also linux distributions want to use GDC with the same GCC version they normally use. So if a distribution uses gcc-4.8.1 but our sources are gcc-4.8.2 only that'd be a problem. The current approach always works for all minor versions.
>

I don't think that would be a problem.  Or at least I've never had to change anything testing minor releases.

On 24 March 2014 07:34, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 23 March 2014 19:28, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>> On 23 March 2014 09:31, Johannes Pfau <nospam@example.com> wrote:
>>> Am Sat, 22 Mar 2014 14:50:22 -0700
>>> schrieb Brad Roberts <braddr@puremagic.com>:
>>>
>>>> On 3/22/14, 12:02 PM, Iain Buclaw wrote:
>>>> > On 22 March 2014 18:20, Johannes Pfau <nospam@example.com> wrote:
>>>> >> See https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13
>>>> >>
>>>> >> (Didn't see this in my local tests, it probably needs a complete
>>>> >> gdc rebuild to happen)
>>>> >
>>>> > Hmm, didn't see that either.
>>>>
>>>> Has the minimum base gcc version moved forward again?
>>>
>>> I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.
>>>
>>
>> In this case, it's a GCC GC bug.
>>
>> Fix incoming.
>
> Still failing with a second unrelated issue.  Looks like wrong code sent to back-end  (trying to compile an ERROR_MARK) - I probably exposed a couple wrong handling of errors in the backend through some refactoring.   What I might end up doing is submitting a new visitor to walk all trees and assert if an error expression is found, that at least safe guards me from having to put in workarounds to handle junk codegen.  :-)

Green again.  I've also bumped the snapshot version to 20140330. :)

http://d.puremagic.com/test-results/?projectid=2

On 3/31/14, 10:06 AM, Iain Buclaw wrote:
> On 24 March 2014 07:34, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>> On 23 March 2014 19:28, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>> On 23 March 2014 09:31, Johannes Pfau <nospam@example.com> wrote:
>>>> Am Sat, 22 Mar 2014 14:50:22 -0700
>>>> schrieb Brad Roberts <braddr@puremagic.com>:
>>>>
>>>>> On 3/22/14, 12:02 PM, Iain Buclaw wrote:
>>>>>> On 22 March 2014 18:20, Johannes Pfau <nospam@example.com> wrote:
>>>>>>> See
>>>>>>> https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13
>>>>>>>
>>>>>>> (Didn't see this in my local tests, it probably needs a complete
>>>>>>> gdc rebuild to happen)
>>>>>>
>>>>>> Hmm, didn't see that either.
>>>>>
>>>>> Has the minimum base gcc version moved forward again?
>>>>
>>>> I don't think that's the case here, at least there's no obvious change
>>>> that could require a newer snapshot.
>>>>
>>>
>>> In this case, it's a GCC GC bug.
>>>
>>> Fix incoming.
>>
>> Still failing with a second unrelated issue.  Looks like wrong code
>> sent to back-end  (trying to compile an ERROR_MARK) - I probably
>> exposed a couple wrong handling of errors in the backend through some
>> refactoring.   What I might end up doing is submitting a new visitor
>> to walk all trees and assert if an error expression is found, that at
>> least safe guards me from having to put in workarounds to handle junk
>> codegen.  :-)
>
> Green again.  I've also bumped the snapshot version to 20140330. :)
>
> http://d.puremagic.com/test-results/?projectid=2

Good for the green.  I'll add support for paying attention to that version file soonish.. but probably not today.