On Wed, 10 Sep 2014 12:20:04 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

write D -> C++ translator and add translated versions to repo too. no, really! this C++ code need not to be maintenable, so we can use C++ subset as "assembler language". i.e. use D frontend to make all analysis, instantiate templates and so on, then just emit ugly, unreadable, but working subset of C++. why C++? to support exceptions, which can be hard to do properly with C.

i'm really serious here. and besides solving bootstraping problems we will have a nice codegen for new platforms: if platform has C++ compiler, we can run D code on in.

sure, there will be problems with GC (let's forget about it for the
first iteration, DMD doesn't do much free()s too) and other things, but
will solve all transition problems.

On 9/10/14, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> - Decide on policy on how many previous releases the current codebase
>   must be buildable on (currently, it's just the previous release, as I
>   understand it);

If by current you mean git-head, only git-head versions of DMD are compatible with git-head versions of druntime and phobos. Meaning it's normal that an e.g. 2.066 compiler will not build a Phobos commit after the commit tagged v2.066 (it may work for a while, but things usually break quick enough either through things like mangling changes or accepts-invalid bug fixes, to name a few).

On Wed, Sep 10, 2014 at 10:58:00PM +0200, Andrej Mitrovic via Digitalmars-d wrote:
> On 9/10/14, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > - Decide on policy on how many previous releases the current
> >   codebase must be buildable on (currently, it's just the previous
> >   release, as I understand it);
> 
> If by current you mean git-head, only git-head versions of DMD are compatible with git-head versions of druntime and phobos. Meaning it's normal that an e.g. 2.066 compiler will not build a Phobos commit after the commit tagged v2.066 (it may work for a while, but things usually break quick enough either through things like mangling changes or accepts-invalid bug fixes, to name a few).

If self-hosting is ever going to take off, we're gonna hafta restrict dmd source code to be compilable with at least the previous dmd release. Otherwise, we may end up with a compiler that can't be compiled unless you've already compiled it first.


T

-- 
In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.

On 9/10/14, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> If that's the case then we're going to have to become much better organized. That means more frequent releases and more targeted releases (surgically picking pulls to be merged rather than merging a random set of pulls that may or may not break backwards compatibility).

And the autotester would have to change to verify a previous release is buildable.

I don't know, self-hosting is a mysterious concept. But it's kind of exciting! :)

On Wed, Sep 10, 2014 at 11:21:23PM +0200, Andrej Mitrovic via Digitalmars-d wrote:
> On 9/10/14, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> > If that's the case then we're going to have to become much better organized. That means more frequent releases and more targeted releases (surgically picking pulls to be merged rather than merging a random set of pulls that may or may not break backwards compatibility).
> 
> And the autotester would have to change to verify a previous release is buildable.
> 
> I don't know, self-hosting is a mysterious concept. But it's kind of exciting! :)

It's definitely exciting! But can also blow up in your face if you don't know what you're doing...


T

-- 
Жил-был король когда-то, при нём блоха жила.

On 9/10/14, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> If self-hosting is ever going to take off, we're gonna hafta restrict dmd source code to be compilable with at least the previous dmd release. Otherwise, we may end up with a compiler that can't be compiled unless you've already compiled it first.

If that's the case then we're going to have to become much better organized. That means more frequent releases and more targeted releases (surgically picking pulls to be merged rather than merging a random set of pulls that may or may not break backwards compatibility).

On 10/09/14 21:20, H. S. Teoh via Digitalmars-d wrote:
> - How to make a nice transition for people who follow git HEAD (whose
>    setups will inevitably fail once the above PR gets pulled, since it
>    will likely be unable to find a working D compiler in order to build
>    itself);

Is it considered immoral to build DDMD with GDC or LDC? ;-)

On Thu, Sep 11, 2014 at 02:04:52AM +0200, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 10/09/14 21:20, H. S. Teoh via Digitalmars-d wrote:
> >- How to make a nice transition for people who follow git HEAD (whose
> >  setups will inevitably fail once the above PR gets pulled, since it
> >  will likely be unable to find a working D compiler in order to
> >  build itself);
> 
> Is it considered immoral to build DDMD with GDC or LDC? ;-)

It's certainly a possibility, provided the makefiles are updated to be able to work with them. :)


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.

On 10 Sep 2014 22:13, "H. S. Teoh via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Wed, Sep 10, 2014 at 10:58:00PM +0200, Andrej Mitrovic via
Digitalmars-d wrote:
> > On 9/10/14, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:
> > > - Decide on policy on how many previous releases the current
> > >   codebase must be buildable on (currently, it's just the previous
> > >   release, as I understand it);
> >
> > If by current you mean git-head, only git-head versions of DMD are compatible with git-head versions of druntime and phobos. Meaning it's normal that an e.g. 2.066 compiler will not build a Phobos commit after the commit tagged v2.066 (it may work for a while, but things usually break quick enough either through things like mangling changes or accepts-invalid bug fixes, to name a few).
>
> If self-hosting is ever going to take off, we're gonna hafta restrict dmd source code to be compilable with at least the previous dmd release. Otherwise, we may end up with a compiler that can't be compiled unless you've already compiled it first.
>

For GDC (and distributions that ship GDC), that would extend to 3 or 4 versions, as gcc releases are a round about, or just over yearly.

Iain.

On 11 September 2014 04:50, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 10 Sep 2014 22:13, "H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
>>
>> On Wed, Sep 10, 2014 at 10:58:00PM +0200, Andrej Mitrovic via Digitalmars-d wrote:
>> > On 9/10/14, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> > > - Decide on policy on how many previous releases the current
>> > >   codebase must be buildable on (currently, it's just the previous
>> > >   release, as I understand it);
>> >
>> > If by current you mean git-head, only git-head versions of DMD are compatible with git-head versions of druntime and phobos. Meaning it's normal that an e.g. 2.066 compiler will not build a Phobos commit after the commit tagged v2.066 (it may work for a while, but things usually break quick enough either through things like mangling changes or accepts-invalid bug fixes, to name a few).
>>
>> If self-hosting is ever going to take off, we're gonna hafta restrict dmd source code to be compilable with at least the previous dmd release. Otherwise, we may end up with a compiler that can't be compiled unless you've already compiled it first.
>>
>
> For GDC (and distributions that ship GDC), that would extend to 3 or 4 versions, as gcc releases are a round about, or just over yearly.
>

By way of example, the version of D shipped with gcc-4.9 in Debian/Ubuntu is 2.065, if we were to switch now, then that compiler version will need to be able to build whatever will be the current when gcc-5.0 comes out.

Iain.