Having an "lts" branch to bootstrap from is great, but it shouldn't be only a moving target. It would be really great if there was either
a) a release/tag of lts corresponding to each release or
b) lts was in some way packaged with the code (a git submodule, or maybe just a folder that's only in releases)

Ideally what I want is to be able to download the source for a release, pass "-DAUTO_BOOTSTRAP" to cmake and get a fully bootstrapped, repeatable build with no binary downloads and no unstable (i.e. git HEAD) dependencies.

On Sunday, 28 February 2016 at 13:06:08 UTC, John Colvin wrote:
> Having an "lts" branch to bootstrap from is great, but it shouldn't be only a moving target. It would be really great if there was either
> a) a release/tag of lts corresponding to each release or
> b) lts was in some way packaged with the code (a git submodule, or maybe just a folder that's only in releases)
>
> Ideally what I want is to be able to download the source for a release, pass "-DAUTO_BOOTSTRAP" to cmake and get a fully bootstrapped, repeatable build with no binary downloads and no unstable (i.e. git HEAD) dependencies.

Hi Colvin!

ltsmaster is used for further development/bug fixing. For bootstrapping, the current 0.17.x release should be used.

The bootstrapping process is yet not finally settled. You describe ideas I already had but I have not yet tried one of them.

We also had the idea to embed the compiler version used to create LDC into the 'ldc2 -version' output. Again, we still need to figure out how to do it.

Regards,
Kai

On Sunday, 28 February 2016 at 16:05:06 UTC, Kai Nacke wrote:
> On Sunday, 28 February 2016 at 13:06:08 UTC, John Colvin wrote:
>> [...]
>
> Hi Colvin!
>
> ltsmaster is used for further development/bug fixing. For bootstrapping, the current 0.17.x release should be used.
>
> The bootstrapping process is yet not finally settled. You describe ideas I already had but I have not yet tried one of them.
>
> We also had the idea to embed the compiler version used to create LDC into the 'ldc2 -version' output. Again, we still need to figure out how to do it.

I think it'd be a good idea to release occasional builds of ltsmaster too, maybe tied to ldc releases, so it's a little bit easier for those who want to use it.

On 1 Mar 2016, at 7:19, Joakim via digitalmars-d-ldc wrote:
> I think it'd be a good idea to release occasional builds of ltsmaster too, maybe tied to ldc releases, so it's a little bit easier for those who want to use it.

I don't think tying them to LDC releases necessarily makes a lot of sense. I'd probably go for simply releasing a new 0.17.x point release every time a certain group of portability issues, etc. has been fixed.

 — David

> On 1 Mar 2016, at 09:57, David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com> wrote:
> I don't think tying them to LDC releases necessarily makes a lot of sense. I'd probably go for simply releasing a new 0.17.x point release every time a certain group of portability issues, etc. has been fixed.
> 
> — David
After you’ve added static linking to 0.17 the easiest way IMHO is to keep a single statically linked 0.17 binary that fits all Linux distros and Mac OS versions (one for platform. there may also be something to do for Windows).
Then update the link to the platform_binary each time the DDMD frontend code requires new language features that are not supported by the previous statically linked ltsmaster.

This way a simple build for a new user is going to be quick and easy, and it will also reduce the amount of required support for it from the LDC maintainers POV.

As a side note — Thinking about back-portability issues, and how easy/painful it may be to support future DDMD language feature on the (then aging 2.068.2 based 0.17), assuming DDMD will go through some refactoring, what could make sense is to also keep an lts2 branch that is ddmd based but does not require new language features that 0.17 cannot support. Then have thew new features added to the ddmd based release, and keep that binary statically linked and available to everyone.
This is just something to keep in mind. I don’t think it should be done/decided now, but on the next MAJOR language feature that is going to be time consuming to back port to 0.17.
This will allow a “trampoline” approach to start with no D compiler at all to a compiler based on D using more steps, but in reality these extra steps will not have to be actually taken as usually people will just start with the current statically compiled “base” to build the required trampoline step and then active master.


Liran