www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: [dmd-internals] DMD now requires a working D compiler to be build

reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
( Replying to 
http://forum.dlang.org/post/54FB47B8.5060204 dawg.eu - sorry, 
can't post to the ML right now )


 First step towards self-hosting DDMD compiler.
 Please update your builds scripts and setups.
 https://github.com/D-Programming-Language/dmd/pull/3970


Congratulations are in order.

I have a question from Digger's perspective:

Which version of DMD will be required to build DDMD?

Will DDMD code be constrained to the feature set of DMD 2.067?

Will future DMD versions promise to never break any DDMD code 
from any point in time?

I certainly hope we aren't going to need a long daisy chain of 
DMD versions in order to build DMD completely from source...
Mar 08 2015
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message 
news:berkxxqbqoxzitsulufd forum.dlang.org...


 Congratulations are in order.

 I have a question from Digger's perspective:

 Which version of DMD will be required to build DDMD?


For now, 2.067.


 Will DDMD code be constrained to the feature set of DMD 2.067?


For now, yes.  If any critical issues come up between now and the eventual 
switch we'll have to bump it.


 Will future DMD versions promise to never break any DDMD code from any 
 point in time?


I don't think that would be practical.


 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?
Mar 08 2015
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
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.

  — David
Mar 08 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/8/2015 9:00 AM, 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.


Trivial in theory, but we all know how fragile that can be in practice.
Mar 08 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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?
Mar 08 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Mar 08 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 9 March 2015 at 04:01:26 UTC, Daniel Murphy wrote:

 "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


A machine-readable version is preferable because then Digger can 
consult it to know which pre-built DMD version to fetch.

If we had somewhere a machine-readable list of all DMD releases 
with binaries for major platforms plus release dates, it could 
use that as well, and just use the latest stable release for the 
point in time which the source code to be built is from.
Mar 09 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message 
news:njvvnodefqmrhzbuxcja forum.dlang.org...


 A machine-readable version is preferable because then Digger can consult 
 it to know which pre-built DMD version to fetch.


Yes.  Any preference on the name?


 If we had somewhere a machine-readable list of all DMD releases with 
 binaries for major platforms plus release dates, it could use that as 
 well, and just use the latest stable release for the point in time which 
 the source code to be built is from.


Can that be generated from the git tags?
Mar 09 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 9 March 2015 at 10:47:06 UTC, Daniel Murphy wrote:

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


 A machine-readable version is preferable because then Digger 
 can consult it to know which pre-built DMD version to fetch.


 Yes.  Any preference on the name?


Not really. There is the VERSION file, maybe something like that.


 If we had somewhere a machine-readable list of all DMD 
 releases with binaries for major platforms plus release dates, 
 it could use that as well, and just use the latest stable 
 release for the point in time which the source code to be 
 built is from.


 Can that be generated from the git tags?


It depends, do we have a stable URL structure for DMD downloads 
so that you can build a working download URL with only the 
platform and version?
Mar 09 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message 
news:bujssfggzyassdtzdegn forum.dlang.org...


 It depends, do we have a stable URL structure for DMD downloads so that 
 you can build a working download URL with only the platform and version?


Sorta http://downloads.dlang.org/releases/2014/
Mar 09 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 9 March 2015 at 13:32:10 UTC, Daniel Murphy wrote:

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


 It depends, do we have a stable URL structure for DMD 
 downloads so that you can build a working download URL with 
 only the platform and version?


 Sorta http://downloads.dlang.org/releases/2014/


That has the year in the URL though...

Can I get that programmatically, other than by querying the git 
tag?
Mar 09 2015
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message 
news:bbnllblbmhtjnkmdthgv forum.dlang.org...


 That has the year in the URL though...

 Can I get that programmatically, other than by querying the git tag?


Not that I know of.
Mar 09 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-03-09 15:40, Vladimir Panteleev wrote:


 That has the year in the URL though...


This might be easier: http://downloads.dlang.org/releases/2.x/

-- 
/Jacob Carlborg
Mar 09 2015
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Sunday, 8 March 2015 at 15:18:25 UTC, Daniel Murphy wrote:

 I would prefer long periods between host compiler version 
 bumps, but is building completely from source really a concern?


 From a release building standpoint a new release must be 
buildable with the last release. I'd even opt for two release 
versions to prevent the use of bleeding edge features.
Mar 08 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 09 Mar 2015 02:18:31 +1100, Daniel Murphy wrote:


 I would prefer long periods between host compiler version bumps, but is
 building completely from source really a concern?


sure it is. one more windoze .exe to call for cross-building dmd.exe in=20
GNU/Linux. i managed to make it partially buildable with cross-mingw=20
(kawabanga!), and now it all again... also, treading crash bug still not=20
fixed, so vanilla dmd.exe keeps crashing with my wine.

oh, crap... how i hate it.=
Mar 09 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/8/2015 7:49 AM, Vladimir Panteleev wrote:

 Congratulations are in order.


Yes.


 I have a question from Digger's perspective:

 Which version of DMD will be required to build DDMD?

 Will DDMD code be constrained to the feature set of DMD 2.067?

 Will future DMD versions promise to never break any DDMD code from any point in
 time?

 I certainly hope we aren't going to need a long daisy chain of DMD versions in
 order to build DMD completely from source...


Hmm. That does leave us with the problem of bootstrapping it on a new platform. 
That would suggest constraining it to be compilable with 2.067.
Mar 08 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 8 March 2015 at 19:58:52 UTC, Walter Bright wrote:

 On 3/8/2015 7:49 AM, Vladimir Panteleev wrote:

 Congratulations are in order.


 Yes.


 I have a question from Digger's perspective:

 Which version of DMD will be required to build DDMD?

 Will DDMD code be constrained to the feature set of DMD 2.067?

 Will future DMD versions promise to never break any DDMD code 
 from any point in
 time?

 I certainly hope we aren't going to need a long daisy chain of 
 DMD versions in
 order to build DMD completely from source...


 Hmm. That does leave us with the problem of bootstrapping it on 
 a new platform. That would suggest constraining it to be 
 compilable with 2.067.


Also: https://issues.dlang.org/show_bug.cgi?id=14255
Mar 08 2015
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 8 March 2015 at 19:58:52 UTC, Walter Bright wrote:

 Hmm. That does leave us with the problem of bootstrapping it on 
 a new platform. That would suggest constraining it to be 
 compilable with 2.067.


Once you fix DMD so that it can cross-compile (or use GDC/LDC), 
this is no longer an issue. Well, if you do not have a C 
toolchain for cross-compilation on your system, linking would be 
a bit tricky, but it would still be doable.

It might be a mild inconvenience, but certainly not an 
insurmountable problem.

  — David
Mar 08 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"David Nadlinger"  wrote in message 
news:ghztksvvlcgmaoycaxcz forum.dlang.org...


 Once you fix DMD so that it can cross-compile (or use GDC/LDC), this is no 
 longer an issue. Well, if you do not have a C toolchain for 
 cross-compilation on your system, linking would be a bit tricky, but it 
 would still be doable.

 It might be a mild inconvenience, but certainly not an insurmountable 
 problem.


I agree, cross-compiling is the way forward.
Mar 08 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:mdi9ls$o10$1 digitalmars.com...


 Hmm. That does leave us with the problem of bootstrapping it on a new 
 platform. That would suggest constraining it to be compilable with 2.067.


If it's a new platform, why would 2.067 be able to target it?
Mar 08 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 08 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Mar 08 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 08 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Mar 08 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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++.
Mar 09 2015
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Mar 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2015 12:30 AM, Daniel Murphy wrote:

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


As far as I'm concerned, if it's running on the same machine, it is not a cross 
compiler, it's a different memory model.



 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.


Yup.
Mar 09 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:mdjj01$22eo$1 digitalmars.com...


 As far as I'm concerned, if it's running on the same machine, it is not a 
 cross compiler, it's a different memory model.


I... I don't agree.  But luckily it doesn't matter.
Mar 09 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 09 Mar 2015 00:12:47 -0700, Walter Bright wrote:


 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.


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


so do you mean that if i need to compile under GNU/Linux, but have=20
compiler to produce windows PE, that means that i'm not doing cross-
compile? no, i will not copy the resulting PE anywhere, i'll test it=20
right on the same box.

a very interesting definition of cross-compilation and cross-compilers...=
Mar 09 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 9 March 2015 at 08:44, ketmar via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Mon, 09 Mar 2015 00:12:47 -0700, Walter Bright wrote:


 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.


 so do you mean that if i need to compile under GNU/Linux, but have
 compiler to produce windows PE, that means that i'm not doing cross-
 compile? no, i will not copy the resulting PE anywhere, i'll test it
 right on the same box.

 a very interesting definition of cross-compilation and cross-compilers...


There's a difference between cross-compiling for a wholly different
platform/architecture vs. compiling on a multiarch-aware platform/cpu
(such as 64->32).
Mar 09 2015
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Mar 08 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 09 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 9 March 2015 at 01:26:10 UTC, 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.


What about source Linux distributions, like Gentoo?

What do other self-hosted languages do in this situation?
Mar 09 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message 
news:vdwvdnzzzhenuybcbxjx forum.dlang.org...


 What about source Linux distributions, like Gentoo?

 What do other self-hosted languages do in this situation?


Download the zip.
Mar 09 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, March 10, 2015 00:41:50 Daniel Murphy via Digitalmars-d wrote:

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


 What about source Linux distributions, like Gentoo?

 What do other self-hosted languages do in this situation?


 Download the zip.


And it's not like dmd would be alone with this problem. Other languages'
compilers are written in the language that they compile as well (e.g.
Haskell's ghc is written in Haskell), so it's not like this is a new
problem. And actually, that's really what you're doing with gcc as well on
gentoo - it's just that it comes with the base install rather than
downloading it from elsewhere, but it's initially built elsewhere, otherwise
gentoo would have nothing to compile with.

- Jonathan M Davis
Mar 10 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 10 March 2015 at 10:33:24 UTC, Jonathan M Davis wrote:

 And it's not like dmd would be alone with this problem. Other 
 languages'
 compilers are written in the language that they compile as well


Yeah, besides you could cross compile to LLVM IR and use whatever 
LLVM tools exists on the target platform from there. Besides, you 
probably have access to an emulator if the target platform is 
really weird.

The move to D based refactored D compiler is very promising. 
Kudos to the people behind this effort!
Mar 10 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/8/15 7:49 AM, Vladimir Panteleev wrote:

 ( Replying to http://forum.dlang.org/post/54FB47B8.5060204 dawg.eu -
 sorry, can't post to the ML right now )


 First step towards self-hosting DDMD compiler.
 Please update your builds scripts and setups.
 https://github.com/D-Programming-Language/dmd/pull/3970


 Congratulations are in order.

 I have a question from Digger's perspective:

 Which version of DMD will be required to build DDMD?

 Will DDMD code be constrained to the feature set of DMD 2.067?


I think that's 2.066.1, right?

BTW I just added https://issues.dlang.org/show_bug.cgi?id=14274. Who 
wants to take it?


Andrei
Mar 10 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:mdnvct$1avc$1 digitalmars.com...


 I think that's 2.066.1, right?


2.066.1 is enough to build idgen.d, but it can't build ddmd on all 
platforms.  Among other things, the varargs fixes are missing.
Mar 10 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/10/15 5:06 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:mdnvct$1avc$1 digitalmars.com...


 I think that's 2.066.1, right?


 2.066.1 is enough to build idgen.d, but it can't build ddmd on all
 platforms.  Among other things, the varargs fixes are missing.


But this is weird - a release being built is required for building, um, 
itself?

I do understand that idgen is a separate executable but the simple view 
is that if dmd 2.067 requires dmd being present, the preexisting dmd 
can't be 2.067.

Or I'm misunderstanding something. The short version is the simpler the 
bootstrapping the better.


Andrei
Mar 10 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 March 2015 at 02:10:12 UTC, Andrei Alexandrescu 
wrote:

 On 3/10/15 5:06 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:mdnvct$1avc$1 digitalmars.com...


 I think that's 2.066.1, right?


 2.066.1 is enough to build idgen.d, but it can't build ddmd on 
 all
 platforms.  Among other things, the varargs fixes are missing.


 But this is weird - a release being built is required for 
 building, um, itself?

 I do understand that idgen is a separate executable but the 
 simple view is that if dmd 2.067 requires dmd being present, 
 the preexisting dmd can't be 2.067.

 Or I'm misunderstanding something. The short version is the 
 simpler the bootstrapping the better.


2.067 doesn't have DMD-built idgen yet. This is only applies to 
current master and thus 2.068
Mar 10 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/10/15 7:13 PM, Dicebot wrote:

 On Wednesday, 11 March 2015 at 02:10:12 UTC, Andrei Alexandrescu wrote:

 On 3/10/15 5:06 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:mdnvct$1avc$1 digitalmars.com...


 I think that's 2.066.1, right?


 2.066.1 is enough to build idgen.d, but it can't build ddmd on all
 platforms.  Among other things, the varargs fixes are missing.


 But this is weird - a release being built is required for building,
 um, itself?

 I do understand that idgen is a separate executable but the simple
 view is that if dmd 2.067 requires dmd being present, the preexisting
 dmd can't be 2.067.

 Or I'm misunderstanding something. The short version is the simpler
 the bootstrapping the better.


 2.067 doesn't have DMD-built idgen yet. This is only applies to current
 master and thus 2.068


Nice, thanks. -- Andrei
Mar 10 2015
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:mdo864$1jbk$1 digitalmars.com...


 But this is weird - a release being built is required for building, um, 
 itself?

 I do understand that idgen is a separate executable but the simple view is 
 that if dmd 2.067 requires dmd being present, the preexisting dmd can't be 
 2.067.

 Or I'm misunderstanding something. The short version is the simpler the 
 bootstrapping the better.


<= 2.067 does not require a host D compiler at all to build.
master requires a host D compiler (but not a very recent one)
Building ddmd requires >= 2.067

So for now, you just need _a_ compiler to build dmd.  If you want to build 
ddmd you will need to upgrade to 2.067.

After the 2.067 release I will start adding ddmd stuff to master, but even 
then you will still be able to build the C++ version of dmd with most old 
versions of dmd2 as host compiler.
Mar 10 2015