March 19
On 2019-03-19 18:01, H. S. Teoh wrote:

> 2) Won't there be bootstrapping issues to consider, if building dmd
> requires build.d, but build.d needs to be compiled with dmd?

Basically the whole compiler is written in D now. Bootstrapping is done by using a pre-compiled binary. For new targets cross-compiling is supposed to be used.

-- 
/Jacob Carlborg
March 19
On Tuesday, 19 March 2019 at 17:01:43 UTC, H. S. Teoh wrote:

> 1) Why not use an existing build system written in D?  There's Button,
> Atila's build tool (sorry forgot what it was called), Dub (ick - sorry),
> etc..

I think you're talking about Reggae (https://github.com/atilaneves/reggae)

I'm not against using it, but it does introduce yet another dependency and yet another layer of abstraction to learn and become familiar with.  And what are Reggae's dependencies?  I'd approve and merge a PR that replaces the current build system with one written in Reggae, but I'd rather not have to learn it.  Also, looking at the Reggae README, it looks very makefile-ish.  I'd rather the end result look more like procedural idiomatic D that I could easily add print statements to or step through with a debugger.

Mike


March 19
On Tue, Mar 19, 2019 at 09:07:23PM +0100, Jacob Carlborg via Digitalmars-d wrote:
> On 2019-03-19 18:01, H. S. Teoh wrote:
> 
> > 2) Won't there be bootstrapping issues to consider, if building dmd requires build.d, but build.d needs to be compiled with dmd?
> 
> Basically the whole compiler is written in D now. Bootstrapping is done by using a pre-compiled binary. For new targets cross-compiling is supposed to be used.
[...]

Precisely my point.  So now instead of a single precompiled binary
(dmd), you have two (dmd + build). When the two go out of sync, things
become "interesting".


T

-- 
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
March 19
On Tuesday, 19 March 2019 at 20:45:06 UTC, H. S. Teoh wrote:
> On Tue, Mar 19, 2019 at 09:07:23PM +0100, Jacob Carlborg via Digitalmars-d wrote:
>> On 2019-03-19 18:01, H. S. Teoh wrote:
>> 
>> > 2) Won't there be bootstrapping issues to consider, if building dmd requires build.d, but build.d needs to be compiled with dmd?
>> 
>> Basically the whole compiler is written in D now. Bootstrapping is done by using a pre-compiled binary. For new targets cross-compiling is supposed to be used.
> [...]
>
> Precisely my point.  So now instead of a single precompiled binary
> (dmd), you have two (dmd + build). When the two go out of sync, things
> become "interesting".

Is that a realistic concern? Say build suddenly lags 10 releases behind dmd. For that to happen, build.d would have to remain unchanged for that long.
Anyway, build.d could embed the version of the compiler with which it was built into itself, and check that against the version of the compiler that it calls for building. When they mismatch, it could rebuild itself (or print a warning).


March 20
On Tuesday, 19 March 2019 at 22:30:20 UTC, Bastiaan Veelo wrote:

> Is that a realistic concern? Say build suddenly lags 10 releases behind dmd. For that to happen, build.d would have to remain unchanged for that long.
> Anyway, build.d could embed the version of the compiler with which it was built into itself, and check that against the version of the compiler that it calls for building. When they mismatch, it could rebuild itself (or print a warning).

build.d is tested in the CI with every PR.

Mike
March 20
On Tue, Mar 19, 2019 at 10:30:20PM +0000, Bastiaan Veelo via Digitalmars-d wrote: [...]
> Anyway, build.d could embed the version of the compiler with which it was built into itself, and check that against the version of the compiler that it calls for building.

Actually, this leads to an interesting idea: what if build.d embeds an executable copy of dmd within itself?  Then it will never be out of sync, and you'll be guaranteed that a working compiler is always available.


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye
March 21
On 2019-03-19 21:45, H. S. Teoh wrote:

> Precisely my point.  So now instead of a single precompiled binary
> (dmd), you have two (dmd + build). When the two go out of sync, things
> become "interesting".

What do you mean with "out of sync"?

-- 
/Jacob Carlborg
March 22
On Tuesday, 19 March 2019 at 20:45:06 UTC, H. S. Teoh wrote:
>
> Precisely my point.  So now instead of a single precompiled binary
> (dmd), you have two (dmd + build). When the two go out of sync, things
> become "interesting".
>
>
> T

This is no concern at all ;-)
You see a DMD compiler is already _required_ to build DMD. We simply use the same host compiler to compile build.d. The CIs enforce that we can always compile DMD with the minimum host compiler and similarly they also enforce the same for build.d.

However, while we can build DMD and run its unittest without Make now, druntime and Phobos don't have the equivalent of `build.d` and `test/run.d` and some of the lesser used DMD Makefile targets like the docs target haven't been ported either, so it will still take a bit of time until we're in a post-make era.


March 22
On Friday, 22 March 2019 at 09:08:51 UTC, Seb wrote:
> On Tuesday, 19 March 2019 at 20:45:06 UTC, H. S. Teoh wrote:
>>
>> Precisely my point.  So now instead of a single precompiled binary
>> (dmd), you have two (dmd + build). When the two go out of sync, things
>> become "interesting".
>>
>>
>> T
>
> This is no concern at all ;-)
> You see a DMD compiler is already _required_ to build DMD. We simply use the same host compiler to compile build.d. The CIs enforce that we can always compile DMD with the minimum host compiler and similarly they also enforce the same for build.d.
>
> However, while we can build DMD and run its unittest without Make now, druntime and Phobos don't have the equivalent of `build.d` and `test/run.d` and some of the lesser used DMD Makefile targets like the docs target haven't been ported either, so it will still take a bit of time until we're in a post-make era.

Bootstrapping is still important, though. There are situations where it is forbidden to install binaries on machines. Only the pre-installed software can be used. That's the situation for example at my work. We get Linux installations corresponding to some arbitrary levels IT has decided. The images are outdated and every tool or software must be compiled from sources. It's Kafkaesque, annoying and a total waste of time (for us, not for IT) but that's what I have to contend with. So to install dmd, I had to go through these steps:
build dmd, very old version 2.067 afaicr, then build newer versions. It has to be build also directly from the git repo. All the other nice tools to build any version (digger and so on) fail on our systems because of the very picky proxy. Yeah, our IT environment is a PITA.

So some indication somewhere which version was the last one that could be built without dmd would be a nice datapoint to have.
March 22
On Friday, 22 March 2019 at 09:49:18 UTC, Patrick Schluter wrote:
> All the other nice tools to build any version (digger and so on) fail on our systems because of the very picky proxy. Yeah, our IT environment is a PITA.

Could you please file some issues at https://github.com/CyberShadow/Digger/issues and mention what's missing in Digger to support this?
Next ›   Last »
1 2