Jump to page: 1 2
Thread overview
Re: GDC 4.7 and frontend/phobos 2.060
Nov 05, 2012
Iain Buclaw
Nov 05, 2012
Iain Buclaw
Nov 05, 2012
Iain Buclaw
Nov 05, 2012
H. S. Teoh
Nov 05, 2012
Iain Buclaw
Nov 05, 2012
Iain Buclaw
Nov 06, 2012
Johannes Pfau
November 05, 2012
On 5 November 2012 15:30, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> Hello all,
>
> Having just successfully build GDC 4.7, I noticed that it still contains only frontend/phobos 2.059.
>
> Is there any chance of seeing 2.060 merged in?  One of the main reasons for building from source was to gain certain bugfixes and improved functionality (including code that I wrote) with GDC, that was not in the distro-packaged version.
>
> On the other hand, I could always build on the basis of 4.8 sources ... :-)
>
> Thanks and best wishes,
>
>     -- Joe

You could try taking the patch from the 2.060 merge on trunk and applying it... other than that I don't plan on making any major changes to the 4.7 branch other than bug fixing (someone can feel free to send backpatches from 2.060 if there's any big blockers).

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
November 05, 2012
On 11/05/2012 05:35 PM, Iain Buclaw wrote:
> You could try taking the patch from the 2.060 merge on trunk and
> applying it... other than that I don't plan on making any major
> changes to the 4.7 branch other than bug fixing (someone can feel free
> to send backpatches from 2.060 if there's any big blockers).

This commit, right?
https://github.com/D-Programming-GDC/GDC/commit/458d3e66da769f00bf6f5b5e3d08db80370aa3f9

Alternatively, in your opinion -- better to take gcc-4.8 sources straight from the GNU downloads, or to try a version from Debian Unstable?

November 05, 2012
On 5 November 2012 15:46, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 11/05/2012 05:35 PM, Iain Buclaw wrote:
>>
>> You could try taking the patch from the 2.060 merge on trunk and applying it... other than that I don't plan on making any major changes to the 4.7 branch other than bug fixing (someone can feel free to send backpatches from 2.060 if there's any big blockers).
>
>
> This commit, right? https://github.com/D-Programming-GDC/GDC/commit/458d3e66da769f00bf6f5b5e3d08db80370aa3f9
>
> Alternatively, in your opinion -- better to take gcc-4.8 sources straight from the GNU downloads, or to try a version from Debian Unstable?
>

Ah, now I remember why I hated the 2.060 merge... so many changes ... :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
November 05, 2012
On 11/05/2012 05:53 PM, Iain Buclaw wrote:
> Ah, now I remember why I hated the 2.060 merge... so many changes ... :o)

Sorry to bring back the trauma :-P

Is there a particular reason not to allow the frontend, druntime and phobos to be git submodules which could be kept up to date with upstream in a more 'live' fashion?  I can imagine it might add extra day-to-day issues but it might save the pain of those huge merges ...

November 05, 2012
On 5 November 2012 16:10, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 11/05/2012 05:53 PM, Iain Buclaw wrote:
>>
>> Ah, now I remember why I hated the 2.060 merge... so many changes ... :o)
>
>
> Sorry to bring back the trauma :-P
>
> Is there a particular reason not to allow the frontend, druntime and phobos to be git submodules which could be kept up to date with upstream in a more 'live' fashion?  I can imagine it might add extra day-to-day issues but it might save the pain of those huge merges ...
>

Because we make changes to DFE, Phobos, Druntime to be compatible with things GDC does that DMD doesn't do.

I have discussed the notion of altering the DFE to be a more shared source base for all compilers - where areas that are DMD-specific in DFE are removed and replaced with hooks.  So to port DFE to your own backend, all you require to do is implement these hooks in your glue code (on top of all the ::toSymbol, ::toIR, ::toObjFile, ::toCtype, routines).

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
November 05, 2012
On Mon, Nov 05, 2012 at 05:40:36PM +0000, Iain Buclaw wrote:
> On 5 November 2012 16:10, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
[...]
> > Is there a particular reason not to allow the frontend, druntime and phobos to be git submodules which could be kept up to date with upstream in a more 'live' fashion?  I can imagine it might add extra day-to-day issues but it might save the pain of those huge merges ...
> >
> 
> Because we make changes to DFE, Phobos, Druntime to be compatible with things GDC does that DMD doesn't do.

If we somehow manage to get 2.060 working for the 4.7 branch, would you take a pull request? ;-)

I know you're focusing on 4.8, but I'm still unable to get it to build correctly, whereas the 4.7 branch works for me. And I'd really like to have 2.060 gdc for some of my D projects.


> I have discussed the notion of altering the DFE to be a more shared source base for all compilers - where areas that are DMD-specific in DFE are removed and replaced with hooks.  So to port DFE to your own backend, all you require to do is implement these hooks in your glue code (on top of all the ::toSymbol, ::toIR, ::toObjFile, ::toCtype, routines).
[...]

I think this is something important to work towards. This will greatly widen the availability of D, which can only be a good thing.


T

-- 
Curiosity kills the cat. Moral: don't be the cat.
November 05, 2012
On 5 November 2012 18:04, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Mon, Nov 05, 2012 at 05:40:36PM +0000, Iain Buclaw wrote:
>> On 5 November 2012 16:10, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> [...]
>> > Is there a particular reason not to allow the frontend, druntime and phobos to be git submodules which could be kept up to date with upstream in a more 'live' fashion?  I can imagine it might add extra day-to-day issues but it might save the pain of those huge merges ...
>> >
>>
>> Because we make changes to DFE, Phobos, Druntime to be compatible with things GDC does that DMD doesn't do.
>
> If we somehow manage to get 2.060 working for the 4.7 branch, would you take a pull request? ;-)
>
> I know you're focusing on 4.8, but I'm still unable to get it to build correctly, whereas the 4.7 branch works for me. And I'd really like to have 2.060 gdc for some of my D projects.
>
>

Yes.

>> I have discussed the notion of altering the DFE to be a more shared source base for all compilers - where areas that are DMD-specific in DFE are removed and replaced with hooks.  So to port DFE to your own backend, all you require to do is implement these hooks in your glue code (on top of all the ::toSymbol, ::toIR, ::toObjFile, ::toCtype, routines).
> [...]
>
> I think this is something important to work towards. This will greatly widen the availability of D, which can only be a good thing.
>
>

Andrei thought very much the same when I last spoke to him, but it's later down the priority list - eg, ARM is a bigger priority atm.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
November 05, 2012
On 11/05/2012 07:15 PM, Iain Buclaw wrote:
> On 5 November 2012 18:04, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
>> If we somehow manage to get 2.060 working for the 4.7 branch, would you
>> take a pull request? ;-)
>>
>> I know you're focusing on 4.8, but I'm still unable to get it to build
>> correctly, whereas the 4.7 branch works for me. And I'd really like to
>> have 2.060 gdc for some of my D projects.
>
> Yes.

Can't make any strong promises here (witness my lousy job of compiling it in the first place!) but I will see what I can do in this respect.

> Andrei thought very much the same when I last spoke to him, but it's
> later down the priority list - eg, ARM is a bigger priority atm.

I do agree with your priority here, but I'd be keen to see the DFE tweaked as you suggest -- anything that lets you keep a cleaner merge relationship with upstream is surely good.
November 05, 2012
On 11/05/2012 05:35 PM, Iain Buclaw wrote:
> You could try taking the patch from the 2.060 merge on trunk and
> applying it... other than that I don't plan on making any major
> changes to the 4.7 branch other than bug fixing (someone can feel free
> to send backpatches from 2.060 if there's any big blockers).

Once pulled in, how do I go about running the unittests on all code (DFE, druntime, phobos) as part of the build process?  (Something worth adding to GDC wiki perhaps?)

November 05, 2012
On 5 November 2012 19:29, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 11/05/2012 05:35 PM, Iain Buclaw wrote:
>>
>> You could try taking the patch from the 2.060 merge on trunk and applying it... other than that I don't plan on making any major changes to the 4.7 branch other than bug fixing (someone can feel free to send backpatches from 2.060 if there's any big blockers).
>
>
> Once pulled in, how do I go about running the unittests on all code (DFE,
> druntime, phobos) as part of the build process?  (Something worth adding to
> GDC wiki perhaps?)
>

make check-d


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
« First   ‹ Prev
1 2