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

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.

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

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 ? :)
>

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.

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

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

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.

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.

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