Hi,

What I see as a technical/design blocker for GDC being able to move forward to being self hosted is that I do not want to maintain two versions of the compiler "glue".  The change between one and the other should be seamless.

To tackle this, I've been backporting regression fixes from D to C++, and aligning the interfaces up so that C++ headers are (almost) identical between GDC and DMD/stable.  I would however like to do this on a more public platform that internally within GDC.

The idea is similar to the dmd-1.x branch.  I am happy to maintain this as a continuation of the C++ implementation, and strive to be as close to the current spec as possible, whilst also putting in big warnings that this branch is deprecated.

Would doing such a thing be OK?

The current C++ implementation is here:

https://github.com/D-Programming-GDC/GDC/tree/master/gcc/d/dfrontend

Differences between this and upstream DMD are documented here:

https://github.com/dlang/dmd/pull/2194

Regards,
Iain.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Sounds good to me. Walter? -- Andrei

On 05/28/2017 07:21 AM, Iain Buclaw via dmd-internals wrote:
> Hi,
> 
> What I see as a technical/design blocker for GDC being able to move
> forward to being self hosted is that I do not want to maintain two
> versions of the compiler "glue".  The change between one and the other
> should be seamless.
> 
> To tackle this, I've been backporting regression fixes from D to C++,
> and aligning the interfaces up so that C++ headers are (almost)
> identical between GDC and DMD/stable.  I would however like to do this
> on a more public platform that internally within GDC.
> 
> The idea is similar to the dmd-1.x branch.  I am happy to maintain
> this as a continuation of the C++ implementation, and strive to be as
> close to the current spec as possible, whilst also putting in big
> warnings that this branch is deprecated.
> 
> Would doing such a thing be OK?
> 
> The current C++ implementation is here:
> 
> https://github.com/D-Programming-GDC/GDC/tree/master/gcc/d/dfrontend
> 
> Differences between this and upstream DMD are documented here:
> 
> https://github.com/dlang/dmd/pull/2194
> 
> Regards,
> Iain.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> 
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

If that would make life easier for Iain, I'm on board. -Walter

On 5/30/2017 9:31 AM, Andrei Alexandrescu via dmd-internals wrote:
> Sounds good to me. Walter? -- Andrei
> 
> On 05/28/2017 07:21 AM, Iain Buclaw via dmd-internals wrote:
>> Hi,
>>
>> What I see as a technical/design blocker for GDC being able to move
>> forward to being self hosted is that I do not want to maintain two
>> versions of the compiler "glue".  The change between one and the other
>> should be seamless.
>>
>> To tackle this, I've been backporting regression fixes from D to C++,
>> and aligning the interfaces up so that C++ headers are (almost)
>> identical between GDC and DMD/stable.  I would however like to do this
>> on a more public platform that internally within GDC.
>>
>> The idea is similar to the dmd-1.x branch.  I am happy to maintain
>> this as a continuation of the C++ implementation, and strive to be as
>> close to the current spec as possible, whilst also putting in big
>> warnings that this branch is deprecated.
>>
>> Would doing such a thing be OK?
>>
>> The current C++ implementation is here:
>>
>> https://github.com/D-Programming-GDC/GDC/tree/master/gcc/d/dfrontend
>>
>> Differences between this and upstream DMD are documented here:
>>
>> https://github.com/dlang/dmd/pull/2194
>>
>> Regards,
>> Iain.
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Well, the intention is that, although the C++ implementation is now in an EOL state, I'll keep up the maintenance of it for a while until GDC is in a position to switch.  It's more of a symbolic badge of approval for the patches I've backported from the D frontend.

This could probably be started by creating a branch of v2.068, rebasing against the last C++ commit in master, then I'll raise a PR for all changes I've made since that point.

Iain.

On 31 May 2017 at 01:56, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:
> If that would make life easier for Iain, I'm on board. -Walter
>
>
> On 5/30/2017 9:31 AM, Andrei Alexandrescu via dmd-internals wrote:
>>
>> Sounds good to me. Walter? -- Andrei
>>
>> On 05/28/2017 07:21 AM, Iain Buclaw via dmd-internals wrote:
>>>
>>> Hi,
>>>
>>> What I see as a technical/design blocker for GDC being able to move forward to being self hosted is that I do not want to maintain two versions of the compiler "glue".  The change between one and the other should be seamless.
>>>
>>> To tackle this, I've been backporting regression fixes from D to C++, and aligning the interfaces up so that C++ headers are (almost) identical between GDC and DMD/stable.  I would however like to do this on a more public platform that internally within GDC.
>>>
>>> The idea is similar to the dmd-1.x branch.  I am happy to maintain this as a continuation of the C++ implementation, and strive to be as close to the current spec as possible, whilst also putting in big warnings that this branch is deprecated.
>>>
>>> Would doing such a thing be OK?
>>>
>>> The current C++ implementation is here:
>>>
>>> https://github.com/D-Programming-GDC/GDC/tree/master/gcc/d/dfrontend
>>>
>>> Differences between this and upstream DMD are documented here:
>>>
>>> https://github.com/dlang/dmd/pull/2194
>>>
>>> Regards,
>>> Iain.
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals@puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

I just setup the auto-tester to test the dmd-cxx branches:

    https://auto-tester.puremagic.com/?projectid=17

One thing that needs to happen for it to build is to catch up with the changes made to the makefiles to put the build output in the generated directory.  I'm sure there's others, but that'll get past the first batch of errors I see right now.

On 6/8/2017 2:58 PM, Iain Buclaw via dmd-internals wrote:
> Well, the intention is that, although the C++ implementation is now in
> an EOL state, I'll keep up the maintenance of it for a while until GDC
> is in a position to switch.  It's more of a symbolic badge of approval
> for the patches I've backported from the D frontend.
>
> This could probably be started by creating a branch of v2.068,
> rebasing against the last C++ commit in master, then I'll raise a PR
> for all changes I've made since that point.
>
> Iain.
>
> On 31 May 2017 at 01:56, Walter Bright via dmd-internals
> <dmd-internals@puremagic.com> wrote:
>> If that would make life easier for Iain, I'm on board. -Walter
>>
>>
>> On 5/30/2017 9:31 AM, Andrei Alexandrescu via dmd-internals wrote:
>>> Sounds good to me. Walter? -- Andrei
>>>
>>> On 05/28/2017 07:21 AM, Iain Buclaw via dmd-internals wrote:
>>>> Hi,
>>>>
>>>> What I see as a technical/design blocker for GDC being able to move
>>>> forward to being self hosted is that I do not want to maintain two
>>>> versions of the compiler "glue".  The change between one and the other
>>>> should be seamless.
>>>>
>>>> To tackle this, I've been backporting regression fixes from D to C++,
>>>> and aligning the interfaces up so that C++ headers are (almost)
>>>> identical between GDC and DMD/stable.  I would however like to do this
>>>> on a more public platform that internally within GDC.
>>>>
>>>> The idea is similar to the dmd-1.x branch.  I am happy to maintain
>>>> this as a continuation of the C++ implementation, and strive to be as
>>>> close to the current spec as possible, whilst also putting in big
>>>> warnings that this branch is deprecated.
>>>>
>>>> Would doing such a thing be OK?
>>>>
>>>> The current C++ implementation is here:
>>>>
>>>> https://github.com/D-Programming-GDC/GDC/tree/master/gcc/d/dfrontend
>>>>
>>>> Differences between this and upstream DMD are documented here:
>>>>
>>>> https://github.com/dlang/dmd/pull/2194
>>>>
>>>> Regards,
>>>> Iain.
>>>> _______________________________________________
>>>> dmd-internals mailing list
>>>> dmd-internals@puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>>
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals@puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

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

On 23 July 2017 at 23:52, Brad Roberts via dmd-internals <dmd-internals@puremagic.com> wrote:
> I just setup the auto-tester to test the dmd-cxx branches:
>
>     https://auto-tester.puremagic.com/?projectid=17
>
> One thing that needs to happen for it to build is to catch up with the changes made to the makefiles to put the build output in the generated directory.  I'm sure there's others, but that'll get past the first batch of errors I see right now.
>
>

Really?  That is a bit of a shame, I'd rather not much around with the build config more than what is strictly necessary.

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

On Sunday, 23 July 2017 at 22:40:13 UTC, Iain Buclaw wrote:
> On 23 July 2017 at 23:52, Brad Roberts via dmd-internals <dmd-internals@puremagic.com> wrote:
>> I just setup the auto-tester to test the dmd-cxx branches:
>>
>>     https://auto-tester.puremagic.com/?projectid=17
>>
>> One thing that needs to happen for it to build is to catch up with the changes made to the makefiles to put the build output in the generated directory.  I'm sure there's others, but that'll get past the first batch of errors I see right now.
>>
>>
>
> Really?  That is a bit of a shame, I'd rather not much around with the build config more than what is strictly necessary.
>
> Iain.

Hi Iain/All,

Thanks for creating the dmd-cxx branch. I used it when porting dmd/druntime and phobos to DragonFlyBSD (see: https://forum.dlang.org/post/bsgxwztbentpvxggahzx@forum.dlang.org).

Is the dmd-cxx going to be available in the future as a starting point for other ports ? Are you / is anyone working on making it compatible with the current master branch (v2.077.x) ? Or is it ok to use a multi stage method (like i did) ?

I used v2.068.2 as the middle stage, instead of v2.072.2 to which you updated dmd-cxx, which i only noticed after i had finished the v2.068.2 version. Is it ok to depend on 2.68.2 instead of the version you chose ?

Regards,

Diederik

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

On 11 December 2017 at 20:28, Diederik de Groot via dmd-internals <dmd-internals@puremagic.com> wrote:
> On Sunday, 23 July 2017 at 22:40:13 UTC, Iain Buclaw wrote:
>>
>> On 23 July 2017 at 23:52, Brad Roberts via dmd-internals <dmd-internals@puremagic.com> wrote:
>>>
>>> I just setup the auto-tester to test the dmd-cxx branches:
>>>
>>>     https://auto-tester.puremagic.com/?projectid=17
>>>
>>> One thing that needs to happen for it to build is to catch up with the changes made to the makefiles to put the build output in the generated directory.  I'm sure there's others, but that'll get past the first batch of errors I see right now.
>>>
>>>
>>
>> Really?  That is a bit of a shame, I'd rather not much around with the build config more than what is strictly necessary.
>>
>> Iain.
>
>
> Hi Iain/All,
>
> Thanks for creating the dmd-cxx branch. I used it when porting dmd/druntime and phobos to DragonFlyBSD (see: https://forum.dlang.org/post/bsgxwztbentpvxggahzx@forum.dlang.org).
>
> Is the dmd-cxx going to be available in the future as a starting point for other ports ? Are you / is anyone working on making it compatible with the current master branch (v2.077.x) ? Or is it ok to use a multi stage method (like i did) ?
>
> I used v2.068.2 as the middle stage, instead of v2.072.2 to which you updated dmd-cxx, which i only noticed after i had finished the v2.068.2 version. Is it ok to depend on 2.68.2 instead of the version you chose ?
>

I would hardly call it 2.072, its just 2.068 but with some regression fixes from latter releases.  The only thing I guarantee it to build is phobos and dmd.

I can't see it being updated beyond a 2.076-ish front-end (which is
what gdc is using).

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

On Monday, 11 December 2017 at 19:42:39 UTC, Iain Buclaw wrote:
> On 11 December 2017 at 20:28, Diederik de Groot via ....
>>
>> Hi Iain/All,
>>
>> Thanks for creating the dmd-cxx branch. I used it when porting dmd/druntime and phobos to DragonFlyBSD (see: https://forum.dlang.org/post/bsgxwztbentpvxggahzx@forum.dlang.org).
>>
>> Is the dmd-cxx going to be available in the future as a starting point for other ports ? Are you / is anyone working on making it compatible with the current master branch (v2.077.x) ? Or is it ok to use a multi stage method (like i did) ?
>>
>> I used v2.068.2 as the middle stage, instead of v2.072.2 to which you updated dmd-cxx, which i only noticed after i had finished the v2.068.2 version. Is it ok to depend on 2.68.2 instead of the version you chose ?
>>
>
> I would hardly call it 2.072, its just 2.068 but with some regression fixes from latter releases.  The only thing I guarantee it to build is phobos and dmd.
>
> I can't see it being updated beyond a 2.076-ish front-end (which is
> what gdc is using).
>
> Iain.

Hi Iain,

Thanks for your timely response !

From the above i gather, from your response, i should be ok with using 2.068 as the intermediate stage.
Using these branches 'dmd-cxx' -> '2.068' -> 'master' seems to be working for me. Currently it is able to pass 99% of the phobos unittests. I am currently working on the last couple of unittests, which seem to point out issues with my porting effort (Differences between FreeBSD and DragonFlyBSD for example).

I tried compiling the master branch with dmd-cxx directly (both on linux as well as on dragonflybsd), but was running into multiple problems. Issues which i could not resolve (Linking issues, Missing references, d-language changes, ie: body->do, etc). Using an intermediate step seemed to resolve this (so i went with that). If it was intented for the `dmd-cxx` branch to be able to compile 'master' directly, we may have to revisit it, and resolve the issues, mentioned above.

If necessary, I will revisit using v2.072 instead of v2.068.2 is/when i run into any problems. Because of my current dependence on having the DragonFlyBSD changes committed to v2.068.2, do you see this as a problem getting the PR committed, later on ?

Regards,

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

Hi Diederik,

On 11 Dec 2017, at 23:16, Diederik de Groot via dmd-internals wrote:
> From the above i gather, from your response, i should be ok with using 2.068 as the intermediate stage.

What might be easier than to use an intermediate stage is getting a DMD version tagged that is 2.068.2, but with the one D dependency removed. 2.068.2 is basically still entirely C++; only some auxiliary code has been converted to D to test the waters

For LDC, more specifically our last C++-based version (0.17.x/ltsmaster branch), we just reverted that change. The resulting 2.068.2-based compiler can directly bootstrap current master.

Best,
David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals