www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD git master stuck at 2.084???

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
I've been building dmd from source since years ago, and only just
noticed today that the dmd binary produced by `make -f posix.mak`
insists that it's language version 2.084.  Why is this??? I thought the
latest release was already up to 2.088??

Running dmd --version says it's 2.084.  Using pragma(msg, __VERSION__)
also returns 2084UL.  What's going on??

Also, I tried compiling and running build.d myself, but it barfs with a
linker error and dies trying to join a thread when an exception was
thrown.  I've no idea what's going on anymore.

What's the correct way of building git master? Is `make -f posix.mak` no
longer the "right" way? How do I get a compiler that's the actual latest
git master? (Besides downloading a nightly, that is. I really would
prefer to build from source.)


T

-- 
Don't throw out the baby with the bathwater. Use your hands...
Sep 25
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 September 2019 at 23:38:09 UTC, H. S. Teoh wrote:
 I've been building dmd from source since years ago, and only 
 just noticed today that the dmd binary produced by `make -f 
 posix.mak` insists that it's language version 2.084.  Why is 
 this???
i think it just pulls the contents of a file ../VERSION. which is in git now... like are you sure you git pulled from upstream and not just one of your own copies?
Sep 25
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Wednesday, 25 September 2019 at 23:38:09 UTC, H. S. Teoh wrote:
 I've been building dmd from source since years ago, and only 
 just noticed today that the dmd binary produced by `make -f 
 posix.mak` insists that it's language version 2.084.  Why is 
 this??? I thought the latest release was already up to 2.088??

 Running dmd --version says it's 2.084.  Using pragma(msg, 
 __VERSION__) also returns 2084UL.  What's going on??

 Also, I tried compiling and running build.d myself, but it 
 barfs with a linker error and dies trying to join a thread when 
 an exception was thrown.  I've no idea what's going on anymore.

 What's the correct way of building git master? Is `make -f 
 posix.mak` no longer the "right" way? How do I get a compiler 
 that's the actual latest git master? (Besides downloading a 
 nightly, that is. I really would prefer to build from source.)


 T
Which platform are you running building on? I just tested on Arch Linux 64-bit with the following: rdmd src/build.d And it produced a binary with the following output for `dmd --version`: DMD64 D Compiler v2.088.0-240-gaf585f61a Copyright (C) 1999-2019 by The D Language Foundation, All Rights Reserved written by Walter Bright I also tried the same on Windows 10 64-bit and it worked with the same results. Mike
Sep 25
next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 26 September 2019 at 00:06:09 UTC, Mike Franklin 
wrote:

 I just tested on Arch Linux 64-bit with the following:

 rdmd src/build.d

 And it produced a binary with the following output for `dmd 
 --version`:

 DMD64 D Compiler v2.088.0-240-gaf585f61a
 Copyright (C) 1999-2019 by The D Language Foundation, All 
 Rights Reserved written by Walter Bright

 I also tried the same on Windows 10 64-bit and it worked with 
 the same results.

 Mike
BTW, build.d only builds dmd. We haven't yet begun creating a build.d for druntime or phobos yet, though we would welcome any help doing so. Mike
Sep 25
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 26, 2019 at 12:06:09AM +0000, Mike Franklin via Digitalmars-d wrote:
[...]
 Which platform are you running building on?
Debian Linux 64-bit.
 I just tested on Arch Linux 64-bit with the following:
 
 rdmd src/build.d
 
 And it produced a binary with the following output for `dmd
 --version`:
 
 DMD64 D Compiler v2.088.0-240-gaf585f61a
 Copyright (C) 1999-2019 by The D Language Foundation, All Rights
 Reserved written by Walter Bright
[...] That's totally weird. I just ran 'rdmd src/build.d' and it said "success", but when I run `generated/linux/release/64/dmd --version` it says: DMD64 D Compiler v2.084.0-2446-gaf585f61a Copyright (C) 1999-2019 by The D Language Foundation, All Rights Reserved written by Walter Bright WAT?? And just in case my git repo is screwed, I checked `git log`, the top commit is: af585f61a10e978f916e896f2d1deac1ee6790e7 dated Sep 26, 2019, which can't possibly be 2.084. I don't get it. T -- When solving a problem, take care that you do not become part of the problem.
Sep 25
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 26 September 2019 at 00:29:07 UTC, H. S. Teoh wrote:

 I don't get it.
Neither do I, but what's in your VERSION file at the root of the DMD repository?
Sep 25
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 26, 2019 at 12:41:33AM +0000, Mike Franklin via Digitalmars-d wrote:
 On Thursday, 26 September 2019 at 00:29:07 UTC, H. S. Teoh wrote:
 
 I don't get it.
Neither do I, but what's in your VERSION file at the root of the DMD repository?
v2.088.0 T -- If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.
Sep 25
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 26 September 2019 at 00:52:48 UTC, H. S. Teoh wrote:
 On Thu, Sep 26, 2019 at 12:41:33AM +0000, Mike Franklin via 
 Digitalmars-d wrote:
 On Thursday, 26 September 2019 at 00:29:07 UTC, H. S. Teoh 
 wrote:
 
 I don't get it.
Neither do I, but what's in your VERSION file at the root of the DMD repository?
v2.088.0 T
dmd build script reads the version from the most recent local tag reachable from the head, and you probably did't fetch all of the recent tags from upstream. 'git fetch/pull --tags' should fix that.
Sep 25
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 26 September 2019 at 05:52:40 UTC, Max Samukha wrote:

 dmd build script reads the version from the most recent local 
 tag reachable from the head, and you probably did't fetch all 
 of the recent tags from upstream. 'git fetch/pull --tags' 
 should fix that.
typo: did't -> didn't
Sep 25
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 26, 2019 at 05:52:40AM +0000, Max Samukha via Digitalmars-d wrote:
[...]
 dmd build script reads the version from the most recent local tag
 reachable from the head, and you probably did't fetch all of the
 recent tags from upstream. 'git fetch/pull --tags' should fix that.
I tried this on a copy of a "bad" dmd repo I had left, and I still get a messed up dmd. Turns out, build.d apparently also uses some kind of caching / timestamping system to determine when to build something, so I had to delete the generated/ directory and rerun it before it did the right thing. I wish build.d would use content hashing for checking if a source file has changed, rather than timestamping, or worse, apparently just the existence of the target. T -- Lottery: tax on the stupid. -- Slashdotter
Sep 26
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 26, 2019 at 04:46:49AM -0700, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Sep 26, 2019 at 05:52:40AM +0000, Max Samukha via Digitalmars-d wrote:
 [...]
 dmd build script reads the version from the most recent local tag
 reachable from the head, and you probably did't fetch all of the
 recent tags from upstream. 'git fetch/pull --tags' should fix that.
[...]
 I wish build.d would use content hashing for checking if a source file
 has changed, rather than timestamping, or worse, apparently just the
 existence of the target.
[...] Mystery solved: the problem was caused by missing tags, *and* the fact that build.d doesn't rebuild when git tags change. T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Sep 26
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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??? T -- Political correctness: socially-sanctioned hypocrisy.
Sep 25
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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 -- Perhaps the most widespread illusion is that if we were in power we would behave very differently from those who now hold it---when, in truth, in order to get power we would have to become very much like them. -- Unknown
Sep 25
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Sep 26
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 26 September 2019 at 11:15:40 UTC, Jonathan Marler 
wrote:
 [snip]

 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.
I've heard you talk about this before, but I haven't tried it yet. Is it something you would ever try to get added to dlang?
Sep 26
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 26 September 2019 at 12:36:00 UTC, jmh530 wrote:
 On Thursday, 26 September 2019 at 11:15:40 UTC, Jonathan Marler 
 wrote:
 [snip]

 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.
I've heard you talk about this before, but I haven't tried it yet. Is it something you would ever try to get added to dlang?
I would consider it. However, this is a fork of rdmd and I think the language maintainers would rather fix rdmd then take all the changes I made on my fork. I was originally making these changes to rdmd itself but there were too many things that I and the other rdmd developers couldn't agree on so my only choice was to fork it where I could make the changes I wanted to make.
Sep 26
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 26, 2019 at 04:26:40PM +0000, Jonathan Marler via Digitalmars-d
wrote:
 On Thursday, 26 September 2019 at 12:36:00 UTC, jmh530 wrote:
[...]
 Is it something you would ever try to get added to dlang?
I would consider it. However, this is a fork of rdmd and I think the language maintainers would rather fix rdmd then take all the changes I made on my fork. I was originally making these changes to rdmd itself but there were too many things that I and the other rdmd developers couldn't agree on so my only choice was to fork it where I could make the changes I wanted to make.
[...] Is your fork available publicly? I think it's good to have some "competition" so that the official version doesn't stagnate. If enough people switch to your fork, it could even make for a strong case to accept your changes regardless of past disagreements. T -- Computers aren't intelligent; they only think they are.
Sep 26
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 26 September 2019 at 16:47:26 UTC, H. S. Teoh wrote:
 On Thu, Sep 26, 2019 at 04:26:40PM +0000, Jonathan Marler via 
 Digitalmars-d wrote:
 [...]
[...]
 [...]
[...] Is your fork available publicly? I think it's good to have some "competition" so that the official version doesn't stagnate. If enough people switch to your fork, it could even make for a strong case to accept your changes regardless of past disagreements. T
Yeah right here: https://github.com/dragon-lang/rund
Sep 26
prev sibling next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
On Thu, Sep 26, 2019 at 6:47 PM H. S. Teoh via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thu, Sep 26, 2019 at 04:26:40PM +0000, Jonathan Marler via Digitalmars-d
wrote:
 On Thursday, 26 September 2019 at 12:36:00 UTC, jmh530 wrote:
[...]
 Is it something you would ever try to get added to dlang?
I would consider it. However, this is a fork of rdmd and I think the language maintainers would rather fix rdmd then take all the changes I made on my fork. I was originally making these changes to rdmd itself but there were too many things that I and the other rdmd developers couldn't agree on so my only choice was to fork it where I could make the changes I wanted to make.
[...] Is your fork available publicly? I think it's good to have some "competition" so that the official version doesn't stagnate. If enough people switch to your fork, it could even make for a strong case to accept your changes regardless of past disagreements. T -- Computers aren't intelligent; they only think they are.
AFAIK his fork is here: https://github.com/marler8997/tools But he has take a different path, he just make a new project which make sense. And he has done excelent job.
Sep 26
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 26 September 2019 at 16:26:40 UTC, Jonathan Marler 
wrote:
 On Thursday, 26 September 2019 at 12:36:00 UTC, jmh530 wrote:
 On Thursday, 26 September 2019 at 11:15:40 UTC, Jonathan 
 Marler wrote:
 [...]
I've heard you talk about this before, but I haven't tried it yet. Is it something you would ever try to get added to dlang?
I would consider it. However, this is a fork of rdmd and I think the language maintainers would rather fix rdmd then take all the changes I made on my fork. I was originally making these changes to rdmd itself but there were too many things that I and the other rdmd developers couldn't agree on so my only choice was to fork it where I could make the changes I wanted to make.
There's no one actively maintaining rdmd. It's essentially frozen: https://github.com/dlang/tools/commits/master/rdmd.d
Sep 26
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 26, 2019 at 10:57:09PM +0000, Seb via Digitalmars-d wrote:
 On Thursday, 26 September 2019 at 16:26:40 UTC, Jonathan Marler wrote:
 On Thursday, 26 September 2019 at 12:36:00 UTC, jmh530 wrote:
 On Thursday, 26 September 2019 at 11:15:40 UTC, Jonathan Marler
 wrote:
 [...]
I've heard you talk about this before, but I haven't tried it yet. Is it something you would ever try to get added to dlang?
I would consider it. However, this is a fork of rdmd and I think the language maintainers would rather fix rdmd then take all the changes I made on my fork. I was originally making these changes to rdmd itself but there were too many things that I and the other rdmd developers couldn't agree on so my only choice was to fork it where I could make the changes I wanted to make.
There's no one actively maintaining rdmd. It's essentially frozen: https://github.com/dlang/tools/commits/master/rdmd.d
Then why isn't Jonathan Marler's version considered for replacing it? A stagnant software project is essentially a dead one. T -- Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.
Sep 26