On 3/8/2015 5:00 PM, Daniel Murphy wrote:
> If it's a new platform, why would 2.067 be able to target it?

Because it'll have a C++ compiler.

On Sunday, 8 March 2015 at 16:00:57 UTC, David Nadlinger wrote:
> On Sunday, 8 March 2015 at 15:18:25 UTC, Daniel Murphy wrote:
>>> I certainly hope we aren't going to need a long daisy chain of DMD versions in order to build DMD completely from source...
>>
>> I would prefer long periods between host compiler version bumps, but is building completely from source really a concern?
>
> I don't think it would be, especially since building the successive stages can be trivially automated using a script if one is so inclined.

OK, then can a file please be added to the DMD source repo which indicates which host DMD version is needed to build it?

"Walter Bright"  wrote in message news:mdiqav$17i8$1@digitalmars.com...

> On 3/8/2015 5:00 PM, Daniel Murphy wrote:
> > If it's a new platform, why would 2.067 be able to target it?
>
> Because it'll have a C++ compiler.

You'd be able to compile the C++ version of 2.067 on this platform, but 2.067 still wouldn't be able to target that platform without patches. Wouldn't it be easier to add support for the new platform into the latest compiler and cross-compile?  IIRC you did something like this in the past when targeting new platforms. 

On 3/8/2015 6:26 PM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:mdiqav$17i8$1@digitalmars.com...
>
>> On 3/8/2015 5:00 PM, Daniel Murphy wrote:
>> > If it's a new platform, why would 2.067 be able to target it?
>>
>> Because it'll have a C++ compiler.
>
> You'd be able to compile the C++ version of 2.067 on this platform, but 2.067
> still wouldn't be able to target that platform without patches. Wouldn't it be
> easier to add support for the new platform into the latest compiler and
> cross-compile?  IIRC you did something like this in the past when targeting new
> platforms.

Never needed to build a cross compiler.

"Walter Bright"  wrote in message news:mdj3l3$1hup$1@digitalmars.com...

> Never needed to build a cross compiler.

You did when adding 64-bit targets.  ie dmd is a 32->64 and 64->32 cross compiler.

Anyway, in this situation:

We want to target new platform X.
Platform X has a c++ compiler but no D compiler available.
2.067 is the last version that can be built without a D compiler.
DMD master can be built with 2.067 or later.

The obvious (to me) way to get a working compiler on the platform is:
1. Add cross-compiling support targeting X to DMD master
2. Cross-compile DMD for X

Or alternatively:
1. Add ability to target X to 2.067 C++ source
2. Compile 2.067 on X with C++ compiler
3. Add ability to target X to DMD master
4. Compile DMD master with native 2.067 dmd binary

The second method is the only one I can think of that requires 2.067 can be compiled C++-only, and it also seems to require a lot more effort than the cross-compiling method.

Which would you expect to use if adding support to dmd for eg arm/linux?
Is there another method I'm missing?

I think the only hard requirement is that there is a binary package available capable of targeting the platform, or the last C++ version can target it.
For platforms that the C++ version has never supported, cross-compiling is the best option to produce the first set of native binaries. 

"Vladimir Panteleev"  wrote in message news:sjlsydcjflglxpwuscpk@forum.dlang.org...

> OK, then can a file please be added to the DMD source repo which indicates which host DMD version is needed to build it?

This seems reasonable.  We could also add a static assert to provide a helpful error message when attempting to build with older versions, as currently it most likely results in memory corruption and segfaults.

Assuming no critical bugs are found in 2.067, that should be the requirement for now.  I think we avoid bumping the version again until a) critical issues are found that significantly hinder dmd's development or b) the newer compiler version offers significant advantages to development.

An example of a would be if a new version of ld stopped accepting the object files generated by 2.067, or we wanted to add a new supported target that 2.067 didn't support.

An example of B would be if changes to the compiler allowed a large performance boost or a lot of code to be deleted.

Another issues is that the old D source may not compile with the latest compiler.  eg the current source will stop building when overriding without override becomes an error.  Sometimes this can be worked around, sometimes it can't. 

On Monday, March 09, 2015 12:26:18 Daniel Murphy via Digitalmars-d wrote:
> "Walter Bright"  wrote in message news:mdiqav$17i8$1@digitalmars.com...
>
> > On 3/8/2015 5:00 PM, Daniel Murphy wrote:
> > > If it's a new platform, why would 2.067 be able to target it?
> >
> > Because it'll have a C++ compiler.
>
> You'd be able to compile the C++ version of 2.067 on this platform, but 2.067 still wouldn't be able to target that platform without patches. Wouldn't it be easier to add support for the new platform into the latest compiler and cross-compile?  IIRC you did something like this in the past when targeting new platforms.

I thought that cross-compiling was pretty much always how you port a compiler to a new platform. Certainly, I don't see how we could require that ddmd forever compile with 2.067. The language is a lot more stable than it used to be, but it isn't _that_ stable.

- Jonathan M Davis

On 3/8/2015 8:43 PM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:mdj3l3$1hup$1@digitalmars.com...
>
>> Never needed to build a cross compiler.
>
> You did when adding 64-bit targets.  ie dmd is a 32->64 and 64->32 cross compiler.

Not really. I never had to compile one one machine and copy the result onto another.


> Anyway, in this situation:
>
> We want to target new platform X.
> Platform X has a c++ compiler but no D compiler available.
> 2.067 is the last version that can be built without a D compiler.
> DMD master can be built with 2.067 or later.
>
> The obvious (to me) way to get a working compiler on the platform is:
> 1. Add cross-compiling support targeting X to DMD master
> 2. Cross-compile DMD for X
>
> Or alternatively:
> 1. Add ability to target X to 2.067 C++ source
> 2. Compile 2.067 on X with C++ compiler
> 3. Add ability to target X to DMD master
> 4. Compile DMD master with native 2.067 dmd binary
>
> The second method is the only one I can think of that requires 2.067 can be
> compiled C++-only, and it also seems to require a lot more effort than the
> cross-compiling method.
>
> Which would you expect to use if adding support to dmd for eg arm/linux?
> Is there another method I'm missing?
>
> I think the only hard requirement is that there is a binary package available
> capable of targeting the platform, or the last C++ version can target it.
> For platforms that the C++ version has never supported, cross-compiling is the
> best option to produce the first set of native binaries.

How easy it is to copy the files over would decide which method is more convenient. Besides, it is likely the vast majority of the work would be in the back end, which remains in C++.

On 3/8/2015 9:07 PM, Jonathan M Davis via Digitalmars-d wrote:
> I thought that cross-compiling was pretty much always how you port a
> compiler to a new platform. Certainly, I don't see how we could require that
> ddmd forever compile with 2.067. The language is a lot more stable than it
> used to be, but it isn't _that_ stable.

About once a week, when I pull all the DMD changes to my machine, it fails because it won't build druntime anymore. So I have to pull the druntime changes. Then it won't build Phobos anymore, so I have to pull that.

And pray that it all will work, because sometimes it doesn't, and I don't know if the problem is in dmd, phobos, or druntime.

This I want to avoid with bootstrapping the compiler. It's just too many things changing simultaneously.

"Walter Bright"  wrote in message news:mdjh6g$215p$1@digitalmars.com...

> Not really. I never had to compile one one machine and copy the result onto another.

It doesn't have to be cross-architecture to be a cross compiler.

> How easy it is to copy the files over would decide which method is more convenient. Besides, it is likely the vast majority of the work would be in the back end, which remains in C++.

I guess that makes sense.  It should be easier to apply a backend patch to two versions than it would be with a large frontend patch.

Anyway, after the new platform is brought up, the original 2.067 still won't be able to target it and will therefore no longer be a suitable minimum host compiler version. This could be fixed by creating a point release for 2.067 that includes the new platform support, or by bumping the version requirement to the latest release.  If we're talking months, then a point release is reasonable.  If 2.067 is years old by then, it's probably best to bump the requirement.

I think keeping the same minimum version the same for at least ~1 year should be reasonable.