www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bump the minimal version required to compile DMD to 2.076.1

reply Seb <seb wilzba.ch> writes:
Motivation
----------

1) It's required for Walter's work on using -betterC for the 
backend conversion:

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

2) We start to run into random failures lately, e.g.

https://github.com/braddr/d-tester/issues/63
https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

3) There's also WIP to move dmd-cxx to 2.076.1:

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

So if we have to bump the minimal dmd version required to build 
DMD anyways for (1), let's be clear about it and state it.

Anyone objecting?
Jan 12 2018
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

 Motivation
 ----------

 1) It's required for Walter's work on using -betterC for the 
 backend conversion:

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

 2) We start to run into random failures lately, e.g.

 https://github.com/braddr/d-tester/issues/63
 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

 3) There's also WIP to move dmd-cxx to 2.076.1:

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

 So if we have to bump the minimal dmd version required to build 
 DMD anyways for (1), let's be clear about it and state it.

 Anyone objecting?


Yes! we cannot keep bumping the version of the compiler, 
personally I find 2.072 rather steep!
really we should be able to build with 2.068.
Jan 12 2018
parent Seb <seb wilzba.ch> writes:
On Friday, 12 January 2018 at 16:21:25 UTC, Stefan Koch wrote:

 On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

 Motivation
 ----------

 1) It's required for Walter's work on using -betterC for the 
 backend conversion:

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

 2) We start to run into random failures lately, e.g.

 https://github.com/braddr/d-tester/issues/63
 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

 3) There's also WIP to move dmd-cxx to 2.076.1:

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

 So if we have to bump the minimal dmd version required to 
 build DMD anyways for (1), let's be clear about it and state 
 it.

 Anyone objecting?


 Yes! we cannot keep bumping the version of the compiler, 
 personally I find 2.072 rather steep!
 really we should be able to build with 2.068.


FYI: There has never been an official bump to 2.072
You can still build dmd with 2.068 - that's the version 
auto-tester uses.

However, I think you didn't understand my question.
We _will_ bump the minimal required version to compile DMD soon 
(see [1]).
That being said, what's the point in wasting hours of hours 
working around the bugs in 2.068.2 when we will do the bump one 
month later anyways?

[1] https://github.com/dlang/dmd/pull/6907
Jan 12 2018
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

 Motivation
 ----------

 1) It's required for Walter's work on using -betterC for the 
 backend conversion:

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


Not really, he just wants to dogfood betterC on the dmd backend 
when it's ported to D.


 2) We start to run into random failures lately, e.g.

 https://github.com/braddr/d-tester/issues/63
 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048


Seem like issues with 32-bit OS X instead.


 3) There's also WIP to move dmd-cxx to 2.076.1:

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


No idea when that will be ready.


 So if we have to bump the minimal dmd version required to build 
 DMD anyways for (1), let's be clear about it and state it.

 Anyone objecting?


This is going to require changes to ldc/gdc CI, as they actually 
maintain and test against that last C++ version of the common D 
frontend.  It will also affect ports to new platforms, as it 
presents another hoop to jump through.

I see little reason to jump now.  If it's done, it needs to be 
clearly documented.
Jan 12 2018
next sibling parent reply Seb <seb wilzba.ch> writes:
On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:

 On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

 Motivation
 ----------

 1) It's required for Walter's work on using -betterC for the 
 backend conversion:

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


 Not really, he just wants to dogfood betterC on the dmd backend 
 when it's ported to D.


Yeah and that requires:

-mv switch
- removal of the generated assert helper functions

Both are features which aren't present in 2.068
The entire reason why the PR wasn't merged yet is because the 
auto-tester hasn't been updated (and no one hacked these features 
into the gdc Perl wrapper).
Jan 12 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 12 January 2018 at 17:17:02 UTC, Seb wrote:

 On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:

 On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

 Motivation
 ----------

 1) It's required for Walter's work on using -betterC for the 
 backend conversion:

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


 Not really, he just wants to dogfood betterC on the dmd 
 backend when it's ported to D.


 Yeah and that requires:

 -mv switch
 - removal of the generated assert helper functions

 Both are features which aren't present in 2.068
 The entire reason why the PR wasn't merged yet is because the 
 auto-tester hasn't been updated (and no one hacked these 
 features into the gdc Perl wrapper).


Let me rephrase what I wrote, as you did mention originally that 
bumping the compiler version was only required for betterC.  
Walter wants to translate the dmd backend to D, but it doesn't 
have to be betterC, as others in that PR thread point out.

On Friday, 12 January 2018 at 17:17:25 UTC, Jonathan Marler wrote:

 On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:

 On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

 2) We start to run into random failures lately, e.g.

 https://github.com/braddr/d-tester/issues/63
 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048


 Seem like issues with 32-bit OS X instead.


 It's actually a bug in dmd 2.068.2.  I was able to reproduce 
 the segfault on my macbook.


Meaning what, it's reproducible with the 64-bit OS X tests also?


 If I went to the next version of dmd, namely, 2.069.0 then the 
 issue went away.  I was also able to get a stack trace:
 ---
 Obj::term(char const*) + 2285
 obj_end(Library*, File*) + 37
 tryMain(unsigned long, char const**) + 12066
 _start + 203
 start + 33
 ---

 The `+ <num> ` is referring to the code offset in bytes from 
 the beginning of the function, so the actual line of code where 
 the invalid access occurs is somewhere inside Obj::term.  
 Unfortunately, that function is quite large (over 700 lines).

 If we want to continue supporting dmd 2.068.2, I would 
 recommend patching this bug.  I don't know how long we have 
 been using this specific version of dmd 2.068.2 on the 
 autotester, does anyone know?


For now, I think you have no choice but to simply work around 
whatever that bug is.  We should drop support for 32-bit OS X 
sometime soon, and if that fixes the issue, you have no problem.
Jan 12 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-01-12 19:45, Joakim wrote:


 For now, I think you have no choice but to simply work around whatever 
 that bug is.  We should drop support for 32-bit OS X sometime soon, and 
 if that fixes the issue, you have no problem.


Exactly. Apple will drop support for running 32bit applications in their 
next major OS release, 10.14.

-- 
/Jacob Carlborg
Jan 13 2018
parent Brad Roberts <braddr puremagic.com> writes:
Typically support isn't dropped the instant the most recent version of 
the OS drops support but rather when the last supported OS release is no 
longer supported.  So, once 10.13 is no longer supported, then we can 
have the conversation about dropping 32 bit binary creation support.


On 1/13/2018 2:14 AM, Jacob Carlborg via Digitalmars-d wrote:

 On 2018-01-12 19:45, Joakim wrote:


 For now, I think you have no choice but to simply work around 
 whatever that bug is.  We should drop support for 32-bit OS X 
 sometime soon, and if that fixes the issue, you have no problem.


 Exactly. Apple will drop support for running 32bit applications in 
 their next major OS release, 10.14.
Jan 13 2018
prev sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:

 On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

 2) We start to run into random failures lately, e.g.

 https://github.com/braddr/d-tester/issues/63
 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048


 Seem like issues with 32-bit OS X instead.


It's actually a bug in dmd 2.068.2.  I was able to reproduce the 
segfault on my macbook.  If I went to the next version of dmd, 
namely, 2.069.0 then the issue went away.  I was also able to get 
a stack trace:
---
Obj::term(char const*) + 2285
obj_end(Library*, File*) + 37
tryMain(unsigned long, char const**) + 12066
_start + 203
start + 33
---

The `+ <num> ` is referring to the code offset in bytes from the 
beginning of the function, so the actual line of code where the 
invalid access occurs is somewhere inside Obj::term.  
Unfortunately, that function is quite large (over 700 lines).

If we want to continue supporting dmd 2.068.2, I would recommend 
patching this bug.  I don't know how long we have been using this 
specific version of dmd 2.068.2 on the autotester, does anyone 
know?
Jan 12 2018
prev sibling next sibling parent Thomas Mader <thomas.mader gmail.com> writes:
On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

 Motivation
 ----------

 1) It's required for Walter's work on using -betterC for the 
 backend conversion:

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

 2) We start to run into random failures lately, e.g.

 https://github.com/braddr/d-tester/issues/63
 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

 3) There's also WIP to move dmd-cxx to 2.076.1:

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

 So if we have to bump the minimal dmd version required to build 
 DMD anyways for (1), let's be clear about it and state it.

 Anyone objecting?


TLDR; I hope dmd needs a properly maintained bootstrap compiler 
branch with release tags of new versions every now and then as 
ldc does.

For packaging dmd on NixOS it is important to have a bootstrap 
compiler because the entire package tree of the distribution is 
build from scratch and no custom binaries can be used. (Well you 
can patch binaries with patchelf but that's not very nice and 
should probably only used for binary blobs)

Currently dmd 2.067.1 is used on NixOS as a bootstrap compiler 
and the last time I tried dmd-cxx it didn't work because of some 
build problems.
dmd 2.067.1 doesn't build with gcc6 which is the default for 
NixOS. This is not much of a problem because it can be easily 
overwritten to use gcc5 for the bootstrap compiler but still.
I also needed to patch things for the newest dmd version which I 
am slowly trying to upstream but since there are no bootstrap 
backports I can't get rid of those patches in the bootstrap 
package.

Which frontend version such a bootstrap branch has doesn't matter 
for me as long as it is maintained and I can build the newest 
version of dmd and all unit tests run successfully.
Jan 12 2018
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

 Motivation
 ----------

 1) It's required for Walter's work on using -betterC for the 
 backend conversion:

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


That is only a putative dependency. Indeed the -mv=<pkg>=<file> 
feature is useful.
If it's just about the backend though, there is a straightforward 
solution.

If we insist on having a backend package (not under dmd)
```
module backend.cod1;
```
then we can simply move the package to the right place
```
mv src/dmd/backend src/backend
```
. Imports of dmd from backend obviously forbidden (should be 
enforced by separate compilation).


 2) We start to run into random failures lately, e.g.

 https://github.com/braddr/d-tester/issues/63
 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

 3) There's also WIP to move dmd-cxx to 2.076.1:

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


We've been through bootstrapping discussions a couple of times, 
so let me repeat what was decided when we made the frontend 
switch from C++ to D.

- Other platforms are bootstrapped by cross-compilation.
- DMD must be compilable with the latest stable/major release of 
dmd, ldc, and gdc.

   To enforce this policy the Travis-CI test was set up.
   Hopefully this original purpose of the Travis-CI hasn't been 
forgotten in the meantime.
- No other guarantees were negotiated.

   Sticking to an ancient compiler defeats the eat your own 
dogfood goal underlying the C++ -> D transition.

The latest released frontend versions are at the moment:
2.078 - dmd (2.078.1)
2.077 - ldc (1.7.0)
2.068 - gdc (6.3.0+2.068.2)

So technically we could only upgrade to 2.068 atm.
Would be good to hear some release plans from the GDC team for 
this year.

==========

Just in case this is what dmd's schedule looks like for 2018.

2.078.0 - 2018-01-01
2.079.0 - 2018-03-01
2.080.0 - 2018-05-01
2.081.0 - 2018-07-01
2.082.0 - 2018-09-01
2.083.0 - 2018-11-01
2.084.0 - 2019-01-01

I wished the semver discussion¹ would have been a bit more 
decisive and we'd started out the year with 8.0.0 (majors every 6 
months, minors every 2 months). Hopefully we take the chance of 
relabeling 2.080.0 to 8.0.0.

[¹]: 
http://forum.dlang.org/post/eghpfllbnvvlskbdpwfj forum.dlang.org
Jan 14 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 14 January 2018 at 19:22:11 UTC, Martin Nowak wrote:

 We've been through bootstrapping discussions a couple of times, 
 so let me repeat what was decided when we made the frontend 
 switch from C++ to D.

 - Other platforms are bootstrapped by cross-compilation.


Realistically, I'm not sure how this is supposed to work beyond 
the initial port.  As Thomas Mader pointed out earlier, most 
packaging systems expect to build from source, which right now 
means starting with the 2.067/2.068 C++ frontend and then porting 
every version needed up till the latest.

So under Seb's proposed scenario, 2.067, 2.076, and 2.078 would 
all need to be ported and integrated into their packaging system. 
If we bump it to 2.082 later, that becomes, 2.067, 2.076, 2.082, 
and the latest at the time, 2.085 or whatever.  This makes it 
more and more difficult for ports.


 - DMD must be compilable with the latest stable/major release 
 of dmd, ldc, and gdc.

   To enforce this policy the Travis-CI test was set up.
   Hopefully this original purpose of the Travis-CI hasn't been 
 forgotten in the meantime.


Yet the dmd and ldc CI, not sure about gdc, explicitly build with 
2.068 to make sure it's still working.  Maybe that's because gdc 
is still on 2.068, but it wasn't clear that that's the reason.


 - No other guarantees were negotiated.

   Sticking to an ancient compiler defeats the eat your own 
 dogfood goal underlying the C++ -> D transition.


Realistically this isn't happening, since the compiler doesn't 
use the stdlib or gc anyway.


 The latest released frontend versions are at the moment:
 2.078 - dmd (2.078.1)
 2.077 - ldc (1.7.0)
 2.068 - gdc (6.3.0+2.068.2)

 So technically we could only upgrade to 2.068 atm.
 Would be good to hear some release plans from the GDC team for 
 this year.

 ==========

 Just in case this is what dmd's schedule looks like for 2018.

 2.078.0 - 2018-01-01
 2.079.0 - 2018-03-01
 2.080.0 - 2018-05-01
 2.081.0 - 2018-07-01
 2.082.0 - 2018-09-01
 2.083.0 - 2018-11-01
 2.084.0 - 2019-01-01

 I wished the semver discussion¹ would have been a bit more 
 decisive and we'd started out the year with 8.0.0 (majors every 
 6 months, minors every 2 months). Hopefully we take the chance 
 of relabeling 2.080.0 to 8.0.0.

 [¹]: 
 http://forum.dlang.org/post/eghpfllbnvvlskbdpwfj forum.dlang.org


I hope that happens, but 18.0 would be better, so it matches the 
year.
Jan 15 2018
parent reply Temtaime <temtaime gmail.com> writes:
And what builds C++ compiler from source ? :)
Jan 15 2018
next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
Exactly, there is no reason to build 2.067, 2.076, and 2.078, just build
the latest one with the previos one. It is common (in case you do not have
dlang compiler in your distribution) to start with downloading existing
binary and compile lastest version as a package, then you can use this
package as a dependency for building new versions.

On Mon, Jan 15, 2018 at 1:15 PM, Temtaime via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 And what builds C++ compiler from source ? :)
Jan 15 2018
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 15 January 2018 at 12:15:27 UTC, Temtaime wrote:

 And what builds C++ compiler from source ? :)


The system C/C++ compiler is already built and there, obviously.  
Since nobody ships a D compiler with their OS, I'm not sure how 
you think that's relevant.

On Monday, 15 January 2018 at 12:36:04 UTC, Daniel Kozak wrote:

 Exactly, there is no reason to build 2.067, 2.076, and 2.078, 
 just build the latest one with the previos one. It is common 
 (in case you do not have dlang compiler in your distribution) 
 to start with downloading existing binary and compile lastest 
 version as a package, then you can use this package as a 
 dependency for building new versions.


There is no existing binary for an OS that doesn't have a port 
yet!

Take the current DragonFlyBSD port that's being done: he had to 
port both dmd 2.067, which is written in C++, and the latest dmd 
master to DragonFly, in order to have source packages for their 
ports repository:

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

If you bump the D compiler required for latest master, he'll have 
to port every bumped D compiler too, ie 2.067, 2.076, and 2.078, 
in order to have a source package.  That's going to be a huge 
pain that will stop many from doing the initial port.
Jan 15 2018
next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
So why not to use cross compilation?

On Mon, Jan 15, 2018 at 2:10 PM, Joakim via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Monday, 15 January 2018 at 12:15:27 UTC, Temtaime wrote:


 And what builds C++ compiler from source ? :)


 The system C/C++ compiler is already built and there, obviously.  Since
 nobody ships a D compiler with their OS, I'm not sure how you think that's
 relevant.

 On Monday, 15 January 2018 at 12:36:04 UTC, Daniel Kozak wrote:


 Exactly, there is no reason to build 2.067, 2.076, and 2.078, just build
 the latest one with the previos one. It is common (in case you do not have
 dlang compiler in your distribution) to start with downloading existing
 binary and compile lastest version as a package, then you can use this
 package as a dependency for building new versions.


 There is no existing binary for an OS that doesn't have a port yet!

 Take the current DragonFlyBSD port that's being done: he had to port both
 dmd 2.067, which is written in C++, and the latest dmd master to DragonFly,
 in order to have source packages for their ports repository:

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

 If you bump the D compiler required for latest master, he'll have to port
 every bumped D compiler too, ie 2.067, 2.076, and 2.078, in order to have a
 source package.  That's going to be a huge pain that will stop many from
 doing the initial port.
Jan 15 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 15 January 2018 at 13:25:26 UTC, Daniel Kozak wrote:

 So why not to use cross compilation?


As I said before, you could do that for the initial port, say 
cross-compiling a build of ldc master for DragonFly by using ldc 
master on linux.  However, from then on, you'd either be stuck 
requiring all your DragonFly users to do the same or checking 
that cross-compiled DragonFly binary into a binary package 
repository somewhere.  I don't think any OS does this, as usually 
the binary packages are all built from source.

However, most source package repositories like ports expect 
everything to be built from source, so you'd still have to port 
2.067 and any other bootstrap D compiler versions needed to do 
everything from source.

This is the lock-in that keeps most systems tied to C/C++, but we 
have no choice but to adapt to that.  If and when dmd gets into 
the base OS now that it's boost-licensed, as some want to do for 
Fedora and elsewhere, that changes for those platforms.

On Monday, 15 January 2018 at 13:51:26 UTC, Daniel Kozak wrote:

 Btw, ther is a gdc which stil uses c++ version of dfrontend, so 
 on DragonFlyBSD you can build dmd using gdc.


Except you'd still have to port that gdc to DragonFly first, so 
gdc changes nothing about the above equation.
Jan 16 2018
parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Tue, Jan 16, 2018 at 12:51 PM, Joakim via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Monday, 15 January 2018 at 13:25:26 UTC, Daniel Kozak wrote:


 So why not to use cross compilation?


 As I said before, you could do that for the initial port, say
 cross-compiling a build of ldc master for DragonFly by using ldc master on
 linux.  However, from then on, you'd either be stuck requiring all your
 DragonFly users to do the same or checking that cross-compiled DragonFly
 binary into a binary package repository somewhere.  I don't think any OS
 does this, as usually the binary packages are all built from source.


And this is exactly what many distributions do, so there is nothing wrong
about it. There is no big difference between C++ compiler or D compiler,
you still need to used some existing binary to build it from source.
Jan 16 2018
parent reply kinke <kinke libero.it> writes:
On Tuesday, 16 January 2018 at 13:09:06 UTC, Daniel Kozak wrote:

 On Tue, Jan 16, 2018 at 12:51 PM, Joakim via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:


 On Monday, 15 January 2018 at 13:25:26 UTC, Daniel Kozak wrote:


 So why not to use cross compilation?


 As I said before, you could do that for the initial port, say 
 cross-compiling a build of ldc master for DragonFly by using 
 ldc master on linux.  However, from then on, you'd either be 
 stuck requiring all your DragonFly users to do the same or 
 checking that cross-compiled DragonFly binary into a binary 
 package repository somewhere.  I don't think any OS does this, 
 as usually the binary packages are all built from source.


 And this is exactly what many distributions do, so there is 
 nothing wrong about it. There is no big difference between C++ 
 compiler or D compiler, you still need to used some existing 
 binary to build it from source.


Where's the proof? ;) - At least for LDC, my impression is that 
Debian/Fedora/... build ltsmaster (C++-based 2.068) first, then 
use that one to build the latest version, and optionally let the 
latest version compile itself for the final release (Fedora).
Jan 16 2018
parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 16 January 2018 at 18:03:41 UTC, kinke wrote:

 On Tuesday, 16 January 2018 at 13:09:06 UTC, Daniel Kozak wrote:

 On Tue, Jan 16, 2018 at 12:51 PM, Joakim via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:


 On Monday, 15 January 2018 at 13:25:26 UTC, Daniel Kozak 
 wrote:


 So why not to use cross compilation?


 As I said before, you could do that for the initial port, say 
 cross-compiling a build of ldc master for DragonFly by using 
 ldc master on linux.  However, from then on, you'd either be 
 stuck requiring all your DragonFly users to do the same or 
 checking that cross-compiled DragonFly binary into a binary 
 package repository somewhere.  I don't think any OS does 
 this, as usually the binary packages are all built from 
 source.


 And this is exactly what many distributions do, so there is 
 nothing wrong about it. There is no big difference between C++ 
 compiler or D compiler, you still need to used some existing 
 binary to build it from source.


 Where's the proof? ;)


Indeed.

We shouldn't bump the required dlang version while knowing that 
it will break current distribution packaging. Before bumping the 
dlang version to something that would require more than one 
bootstrap step from C++, let's make sure that the distributions 
that we care about have something set up _already_ that meets the 
new dlang version requirement.

-Johan
Jan 16 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 16, 2018 at 10:13:31PM +0000, Johan Engelen via Digitalmars-d wrote:
[...]

 We shouldn't bump the required dlang version while knowing that it
 will break current distribution packaging. Before bumping the dlang
 version to something that would require more than one bootstrap step
 from C++, let's make sure that the distributions that we care about
 have something set up _already_ that meets the new dlang version
 requirement.


[...]

Is there currently a viable cross-compiler for D?  That would solve, in
theory anyway, the bootstrapping problem.  I suppose to be truly viable,
we'd need dmd to be able to cross-compile, which AFAIK it can't just yet.


T

-- 
Fact is stranger than fiction.
Jan 16 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 16 January 2018 at 22:11:46 UTC, H. S. Teoh wrote:

 On Tue, Jan 16, 2018 at 10:13:31PM +0000, Johan Engelen via 
 Digitalmars-d wrote: [...]

 We shouldn't bump the required dlang version while knowing 
 that it will break current distribution packaging. Before 
 bumping the dlang version to something that would require more 
 than one bootstrap step from C++, let's make sure that the 
 distributions that we care about have something set up 
 _already_ that meets the new dlang version requirement.


 [...]

 Is there currently a viable cross-compiler for D?  That would 
 solve, in theory anyway, the bootstrapping problem.  I suppose 
 to be truly viable, we'd need dmd to be able to cross-compile, 
 which AFAIK it can't just yet.


Ldc has proven to be very viable.  kinke has demonstrated using 
it on linux/x64 to cross-compile for Windows:

https://github.com/ldc-developers/ldc/releases/tag/v1.3.0

The ldc package for Android/ARM in the Termux app is 
cross-compiled from linux/x64:

https://github.com/termux/termux-packages/blob/master/packages/ldc/build.sh

However, while this makes it easier to do the initial port to a 
new platform, you still come up against the bootstrapping from 
source requirements of source package repositories, as I pointed 
out above.
Jan 16 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, January 17, 2018 05:39:31 Joakim via Digitalmars-d wrote:

 On Tuesday, 16 January 2018 at 22:11:46 UTC, H. S. Teoh wrote:

 On Tue, Jan 16, 2018 at 10:13:31PM +0000, Johan Engelen via
 Digitalmars-d wrote: [...]


 We shouldn't bump the required dlang version while knowing
 that it will break current distribution packaging. Before
 bumping the dlang version to something that would require more
 than one bootstrap step from C++, let's make sure that the
 distributions that we care about have something set up
 _already_ that meets the new dlang version requirement.


 [...]

 Is there currently a viable cross-compiler for D?  That would
 solve, in theory anyway, the bootstrapping problem.  I suppose
 to be truly viable, we'd need dmd to be able to cross-compile,
 which AFAIK it can't just yet.


 Ldc has proven to be very viable.  kinke has demonstrated using
 it on linux/x64 to cross-compile for Windows:

 https://github.com/ldc-developers/ldc/releases/tag/v1.3.0

 The ldc package for Android/ARM in the Termux app is
 cross-compiled from linux/x64:

 https://github.com/termux/termux-packages/blob/master/packages/ldc/build.s
 h

 However, while this makes it easier to do the initial port to a
 new platform, you still come up against the bootstrapping from
 source requirements of source package repositories, as I pointed
 out above.


_Most_ languages have a compiler written in their own language rather than
C/C++, and I cannot imagine that it's common practice for any of them to go
back to a version that was built using C/C++ and bootstrap from there.

Honestly, I don't see how this could possibly be an issue. This is something
that is already dealt with all the time by folks packaging stuff - whether
you're talking ports for BSD or packages for whatever Linux distro you want
- this is something that they're already dealing with without requiring that
everything be built starting with a C/C++ compiler.

I fully expect that in the long-term, folks porting to new platforms will
use a cross-compiler, and anyone building packages for whatever OS they're
dealing with is just going to use the existing compiler. That's what folks
do even when they're building the entire distro from source. They use
existing compilers to do it. They may not then package the existing
compilers, but they're going to use ones that they already have - either on
a host system or that they pull them in from elsewhere.

Honestly, I think that this whole conversation is worrying about a whole lot
of nothing. We're dealing with a problem that has already been solved by
many other languages, and I don't think that you're going to find any of
them claiming that you need to use a compiler from several years ago to
compile the current compiler, let alone claiming that you need to compile a
C/C++ version of their compiler so that you can build the current compiler.

- Jonathan M Davis
Jan 16 2018
parent Joakim <dlang joakim.fea.st> writes:
On Wednesday, 17 January 2018 at 05:50:12 UTC, Jonathan M Davis 
wrote:

 On Wednesday, January 17, 2018 05:39:31 Joakim via 
 Digitalmars-d wrote:

 On Tuesday, 16 January 2018 at 22:11:46 UTC, H. S. Teoh wrote:

 On Tue, Jan 16, 2018 at 10:13:31PM +0000, Johan Engelen via 
 Digitalmars-d wrote: [...]


 We shouldn't bump the required dlang version while knowing 
 that it will break current distribution packaging. Before 
 bumping the dlang version to something that would require 
 more than one bootstrap step from C++, let's make sure that 
 the distributions that we care about have something set up 
 _already_ that meets the new dlang version requirement.


 [...]

 Is there currently a viable cross-compiler for D?  That 
 would solve, in theory anyway, the bootstrapping problem.  I 
 suppose to be truly viable, we'd need dmd to be able to 
 cross-compile, which AFAIK it can't just yet.


 Ldc has proven to be very viable.  kinke has demonstrated 
 using it on linux/x64 to cross-compile for Windows:

 https://github.com/ldc-developers/ldc/releases/tag/v1.3.0

 The ldc package for Android/ARM in the Termux app is 
 cross-compiled from linux/x64:

 https://github.com/termux/termux-packages/blob/master/packages/ldc/build.s h

 However, while this makes it easier to do the initial port to 
 a new platform, you still come up against the bootstrapping 
 from source requirements of source package repositories, as I 
 pointed out above.


 _Most_ languages have a compiler written in their own language 
 rather than C/C++, and I cannot imagine that it's common 
 practice for any of them to go back to a version that was built 
 using C/C++ and bootstrap from there.

 Honestly, I don't see how this could possibly be an issue. This 
 is something that is already dealt with all the time by folks 
 packaging stuff - whether you're talking ports for BSD or 
 packages for whatever Linux distro you want - this is something 
 that they're already dealing with without requiring that 
 everything be built starting with a C/C++ compiler.

 I fully expect that in the long-term, folks porting to new 
 platforms will use a cross-compiler, and anyone building 
 packages for whatever OS they're dealing with is just going to 
 use the existing compiler. That's what folks do even when 
 they're building the entire distro from source. They use 
 existing compilers to do it. They may not then package the 
 existing compilers, but they're going to use ones that they 
 already have - either on a host system or that they pull them 
 in from elsewhere.

 Honestly, I think that this whole conversation is worrying 
 about a whole lot of nothing. We're dealing with a problem that 
 has already been solved by many other languages, and I don't 
 think that you're going to find any of them claiming that you 
 need to use a compiler from several years ago to compile the 
 current compiler, let alone claiming that you need to compile a 
 C/C++ version of their compiler so that you can build the 
 current compiler.


You're right, I should have checked before saying I didn't think 
any OS used binary packages to build their source packages.  
Looking it up now, this is exactly what FreeBSD ports and NetBSD 
pkgsrc do, using pre-built bootstrap compiler binaries of ghc to 
build the latest ghc:

https://svnweb.freebsd.org/ports/head/lang/ghc/Makefile?revision=457355&view=markup
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/ghc/Makefile?rev=1.56&content-type=text/x-cvsweb-markup

Even the aforementioned NixOS seems to do the same for ghc, so I 
guess Thomas Mader was wrong earlier?

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/ghc/8.2.1-binary.nix

Since this was the only objection I had to bumping the required D 
bootstrap compiler version, I don't have any objection anymore, 
as long as it's prominently documented that we expect new OS 
ports to be cross-compiled initially.

Also, I was looking at tying Iain's C++ 2.076 frontend to the dmd 
backend because I thought we needed a dmd-cxx branch for porters 
to use as a bootstrap compiler on their platforms.  If we're 
going to bump the required version and make porters cross-compile 
initially, I suppose there's no reason to waste any more time on 
such a dmd-cxx branch.
Jan 16 2018
prev sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
Btw, ther is a gdc which stil uses c++ version of dfrontend, so on DragonFlyBSD
you can build dmd using gdc.

On Mon, Jan 15, 2018 at 2:25 PM, Daniel Kozak <kozzi11 gmail.com> wrote:


 So why not to use cross compilation?

 On Mon, Jan 15, 2018 at 2:10 PM, Joakim via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:


 On Monday, 15 January 2018 at 12:15:27 UTC, Temtaime wrote:


 And what builds C++ compiler from source ? :)


 The system C/C++ compiler is already built and there, obviously.  Since
 nobody ships a D compiler with their OS, I'm not sure how you think that's
 relevant.

 On Monday, 15 January 2018 at 12:36:04 UTC, Daniel Kozak wrote:


 Exactly, there is no reason to build 2.067, 2.076, and 2.078, just build
 the latest one with the previos one. It is common (in case you do not have
 dlang compiler in your distribution) to start with downloading existing
 binary and compile lastest version as a package, then you can use this
 package as a dependency for building new versions.


 There is no existing binary for an OS that doesn't have a port yet!

 Take the current DragonFlyBSD port that's being done: he had to port both
 dmd 2.067, which is written in C++, and the latest dmd master to DragonFly,
 in order to have source packages for their ports repository:

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

 If you bump the D compiler required for latest master, he'll have to port
 every bumped D compiler too, ie 2.067, 2.076, and 2.078, in order to have a
 source package.  That's going to be a huge pain that will stop many from
 doing the initial port.
Jan 15 2018