• John Colvin (10/10) Feb 28 2016 Having an "lts" branch to bootstrap from is great, but it
• Kai Nacke (11/21) Feb 28 2016 Hi Colvin!
• Joakim (4/15) Feb 29 2016 I think it'd be a good idea to release occasional builds of
• David Nadlinger via digitalmars-d-ldc (5/8) Feb 29 2016 I don't think tying them to LDC releases necessarily makes a lot of
• Liran Zvibel via digitalmars-d-ldc (7/11) Mar 01 2016 After you’ve added static linking to 0.17 the easiest way IMHO is to k...

John Colvin <john.loughran.colvin gmail.com> writes:

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.

Kai Nacke <kai redstar.de> writes:

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

Joakim <dlang joakim.fea.st> writes:

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.

David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:

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

Liran Zvibel via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:

 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