DMD git master stuck at 2.084???

[Jonathan Marler]

On Thursday, 26 September 2019 at 00:49:49 UTC, H. S. Teoh wrote:
> On Wed, Sep 25, 2019 at 05:40:51PM -0700, H. S. Teoh via 
> Digitalmars-d wrote:
>> On Wed, Sep 25, 2019 at 05:29:07PM -0700, H. S. Teoh via 
>> Digitalmars-d wrote: [...]
>> > 	DMD64 D Compiler v2.084.0-2446-gaf585f61a
>> > 	Copyright (C) 1999-2019 by The D Language Foundation, All 
>> > Rights
>> > 	Reserved written by Walter Bright
>> 
>> OK, it gets stranger. So, I thought perhaps my git repo is 
>> somehow corrupted, so I nuked the whole thing and re-cloned 
>> from github, then ran `rdmd src/build.d`.  The resulting 
>> binary produces even stranger output with --version now:
>> 
>> 	DMD64 D Compiler v2.058-20347-gaf585f61a
>> 	Copyright (C) 1999-2019 by The D Language Foundation, All 
>> Rights
>> 	Reserved written by Walter Bright
>> 
>> 2.058??!  Where did that come from???
> [...]
>
> OK, I *think* I solved the mystery... the utterly evil rdmd 
> cache!!! I nuked the repo, did a fresh git clone, and then ran 
> rdmd --force src/build.d, and finally I get a sane binary:
>
> 	DMD64 D Compiler v2.088.0-240-gaf585f61a
> 	Copyright (C) 1999-2019 by The D Language Foundation, All 
> Rights
> 	Reserved written by Walter Bright
>
> In retrospect, it's probably because I haven't updated my rdmd 
> in years: rdmd --version gives:
>
> 	rdmd build 20170608
> 	Usage: rdmd [RDMD AND DMD OPTIONS]... program [PROGRAM 
> OPTIONS]...
> 	Builds (with dependents) and runs a D program.
> 	Example: rdmd -release myprog --myprogparm 5
> 	[ ... snipped ... ]
>
> I've no idea *what* was in the old rdmd cache... cached copies 
> of older compilers? Cached copies of build.d?!  Whatever it 
> was, it's truly bizarre.
>
>
> T

VERSION is indeed generated from source code inside `build.d`, so 
if your cached binary of `build.d` was indeed be used then this 
would explain it.

https://github.com/dlang/dmd/blob/master/src/build.d#L278

When I forked rdmd to make rund, I had to fix a fair amount bugs 
when it came to calculating the hash for the cache location.  
Bugs that would cause this sort of problem.  How rdmd should work 
is that if the source code changes then it should re-compile no 
matter what.  It uses the timestamp for this though, so if the 
timestamp of build.d somehow never changed or got older than it 
would never update the cached binary of it.

Next time this happens try adding the --chatty argument to rdmd 
and maybe you'll find out why the cache wasn't working right.  
You may or may not get the answer with rdmd but with rund you'll 
always see a line that says:

COMPILE(YES or NO): REASON

i.e.

COMPILE(YES) updated file 'src/build.d'

If you use rdmd alot, consider using my rund fork 
https://github.com/dragon-lang/rund as it runs about twice as 
fast.  It makes my workflow snappier, has fixed a good amount of 
bugs, adds a new feature for adding compiler options in the main 
source file and has better logging of what it's doing.