www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd git master version

reply "H. S. Teoh" <hsteoh qfbox.info> writes:
The current official release of dmd is 2.100.2, but when I build from
the git repo, `dmd --version` says:

	DMD64 D Compiler v2.098.1-10051-g61d7d56a0
	Copyright (C) 1999-2022 by The D Language Foundation, All Rights Reserved
written by Walter Bright

Why is it still reporting 2.098.1?  Isn't that like several releases
behind already?


T

-- 
In order to understand recursion you must first understand recursion.
Oct 12 2022
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 12 October 2022 at 19:04:26 UTC, H. S. Teoh wrote:

 The current official release of dmd is 2.100.2, but when I 
 build from the git repo, `dmd --version` says:


Some thinks that come to mind:
- Is your repo up to date with dlang/dmd?
- Is the `dmd` command actually executing the dmd you built?
- Do you have a locally overridden VERSION file in the root?
Oct 12 2022
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Oct 12, 2022 at 07:22:57PM +0000, Dennis via Digitalmars-d wrote:

 On Wednesday, 12 October 2022 at 19:04:26 UTC, H. S. Teoh wrote:

 The current official release of dmd is 2.100.2, but when I build from
 the git repo, `dmd --version` says:


 
 Some thinks that come to mind:
 - Is your repo up to date with dlang/dmd?


Just pulled from github just now.



 - Is the `dmd` command actually executing the dmd you built?


Yes.  I even `git clean -dfx` in the dmd repo and rebuilt, just to make
sure.



 - Do you have a locally overridden VERSION file in the root?


The VERSION file says:

	v2.100.2

Hmm.


T

-- 
I see that you JS got Bach.
Oct 12 2022
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/12/22 3:04 PM, H. S. Teoh wrote:

 The current official release of dmd is 2.100.2, but when I build from
 the git repo, `dmd --version` says:
 
 	DMD64 D Compiler v2.098.1-10051-g61d7d56a0
 	Copyright (C) 1999-2022 by The D Language Foundation, All Rights Reserved
written by Walter Bright
 
 Why is it still reporting 2.098.1?  Isn't that like several releases
 behind already?
 
 
 T
 


That looks like a git version tag + some commit.

When you pull the remote branch in, do you specify --tags? You may not 
be acquiring all the git tags into your local repo.

-Steve
Oct 12 2022
next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Oct 12, 2022 at 04:31:20PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:

 On 10/12/22 3:04 PM, H. S. Teoh wrote:

 The current official release of dmd is 2.100.2, but when I build from
 the git repo, `dmd --version` says:
 
 	DMD64 D Compiler v2.098.1-10051-g61d7d56a0
 	Copyright (C) 1999-2022 by The D Language Foundation, All Rights Reserved
written by Walter Bright
 
 Why is it still reporting 2.098.1?  Isn't that like several releases
 behind already?




[...]

 That looks like a git version tag + some commit.
 
 When you pull the remote branch in, do you specify --tags? You may not
 be acquiring all the git tags into your local repo.


[...]

You mean it acquires the version number from git tags??  That explains a
lot. :-D


T

-- 
Never criticize a man until you've walked a mile in his shoes. Then when you do
criticize him, you'll be a mile away and he won't have his shoes.
Oct 12 2022
prev sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Oct 12, 2022 at 04:31:20PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]

 When you pull the remote branch in, do you specify --tags? You may not
 be acquiring all the git tags into your local repo.


[...]

Re-pulled with --tags and rebuilt.  Now dmd reports:

	DMD64 D Compiler v2.100.2

	Copyright (C) 1999-2022 by The D Language Foundation, All Rights Reserved
written by Walter Bright

Now *that* sounds more like it. :-D

Thanks for the tip. (Though I must say, it strikes me as a little odd to
key the version number off git tags, which are fluid and
arbitrarily-assigned, as opposed to actual source code that reflects the
actual functionality behind a particular version number...)


T

-- 
What doesn't kill me makes me stranger.
Oct 12 2022
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/12/22 4:45 PM, H. S. Teoh wrote:


 Thanks for the tip. (Though I must say, it strikes me as a little odd to
 key the version number off git tags, which are fluid and
 arbitrarily-assigned, as opposed to actual source code that reflects the
 actual functionality behind a particular version number...)


The main benefit is if you build with a non-tagged version, you can know 
exactly which commit caused your abomination to exist.

And also, git tags are somewhat fluid, but also pretty rigid, it takes a 
lot to delete them and update the server to the new one.

-Steve
Oct 12 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Oct 12, 2022 at 05:06:25PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:

 On 10/12/22 4:45 PM, H. S. Teoh wrote:
 

 Thanks for the tip. (Though I must say, it strikes me as a little
 odd to key the version number off git tags, which are fluid and
 arbitrarily-assigned, as opposed to actual source code that reflects
 the actual functionality behind a particular version number...)


 
 The main benefit is if you build with a non-tagged version, you can
 know exactly which commit caused your abomination to exist.


Including the git commit hash in the version number is generally a good
idea IMO.  But what strikes me as odd is keying the official release
version number on a git tag -- to the point that even __VERSION__
reports 2098L in spite of the compiler being functionally already
2.100.2.  This leads to potentially "interesting" effects when this
compiler is then used to compile code that checks __VERSION__ with
static if...  (This makes the 2.100.2 compiler insist that it's 2.098,
and even convince itself that it's 2.098, but functionally it's actually
2.100.2.)



 And also, git tags are somewhat fluid, but also pretty rigid, it takes
 a lot to delete them and update the server to the new one.


[...]

But when someone clones your repo and forgets to download the tags, you
end up with confused compilers who think they're a different version
from what they actually are. :-D


T

-- 
Just because you can, doesn't mean you should.
Oct 12 2022
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/12/22 5:46 PM, H. S. Teoh wrote:

 Including the git commit hash in the version number is generally a good
 idea IMO.  But what strikes me as odd is keying the official release
 version number on a git tag -- to the point that even __VERSION__
 reports 2098L in spite of the compiler being functionally already
 2.100.2.  This leads to potentially "interesting" effects when this
 compiler is then used to compile code that checks __VERSION__ with
 static if...  (This makes the 2.100.2 compiler insist that it's 2.098,
 and even convince itself that it's 2.098, but functionally it's actually
 2.100.2.)


Yeah, that is odd.

-Steve
Oct 12 2022
prev sibling next sibling parent reply norm <norm.rowtree gmail.com> writes:
On Wednesday, 12 October 2022 at 20:45:43 UTC, H. S. Teoh wrote:

 On Wed, Oct 12, 2022 at 04:31:20PM -0400, Steven Schveighoffer 
 via Digitalmars-d wrote: [...]

 When you pull the remote branch in, do you specify --tags? You 
 may not be acquiring all the git tags into your local repo.


 [...]

 Re-pulled with --tags and rebuilt.  Now dmd reports:

 	DMD64 D Compiler v2.100.2

 	Copyright (C) 1999-2022 by The D Language Foundation, All 
 Rights Reserved written by Walter Bright

 Now *that* sounds more like it. :-D

 Thanks for the tip. (Though I must say, it strikes me as a 
 little odd to key the version number off git tags, which are 
 fluid and arbitrarily-assigned, as opposed to actual source 
 code that reflects the actual functionality behind a particular 
 version number...)


 T


Using git tags is quite common in places where I've worked. CI/CD 
is configured to build a release with changelog and release note 
when it sees a semantic version tag arrive.

To create a release pack we simlpy run:
```
$ git tag -a vX.Y.Z -m "Tag release X.Y.Z" && git push origin 
--tags
```

To get the release information you just

```
$ git describe --long --dirty --match "v*.*.*"
v1.2.3-0-gabcd12345
```

This `v1.2.3-0-gabcd12345` clearly indicates the version, if it 
is actually a release build, and the commit hash, which for us we 
find most important. One less dereference we have to do when bugs 
are reported.

But we might be oddballs I guess, we refuse to use merge commits 
and insist on a linear history :)
Oct 12 2022
next sibling parent norm <norm.rowtree gmail.com> writes:
On Thursday, 13 October 2022 at 03:52:57 UTC, norm wrote:

 On Wednesday, 12 October 2022 at 20:45:43 UTC, H. S. Teoh wrote:

 On Wed, Oct 12, 2022 at 04:31:20PM -0400, Steven Schveighoffer 
 via Digitalmars-d wrote: [...]

 [...]


 [...]

 Re-pulled with --tags and rebuilt.  Now dmd reports:

 	DMD64 D Compiler v2.100.2

 	Copyright (C) 1999-2022 by The D Language Foundation, All 
 Rights Reserved written by Walter Bright

 Now *that* sounds more like it. :-D

 Thanks for the tip. (Though I must say, it strikes me as a 
 little odd to key the version number off git tags, which are 
 fluid and arbitrarily-assigned, as opposed to actual source 
 code that reflects the actual functionality behind a 
 particular version number...)


 T


 Using git tags is quite common in places where I've worked. 
 CI/CD is configured to build a release with changelog and 
 release note when it sees a semantic version tag arrive.

 To create a release pack we simlpy run:
 ```
 $ git tag -a vX.Y.Z -m "Tag release X.Y.Z" && git push origin 
 --tags
 ```

 To get the release information you just

 ```
 $ git describe --long --dirty --match "v*.*.*"
 v1.2.3-0-gabcd12345
 ```

 This `v1.2.3-0-gabcd12345` clearly indicates the version, if it 
 is actually a release build, and the commit hash, which for us 
 we find most important. One less dereference we have to do when 
 bugs are reported.

 But we might be oddballs I guess, we refuse to use merge 
 commits and insist on a linear history :)


I should point out too that github, gitlab, bitbucket et. al. 
have the protect tags feature and understand this approach. So a 
release tag is protected and not fluid, our script also easily do 
this too with a a simple regex. All other tags are fluid, and 
largely  irrelevant tbh we hardly use tags for anything but 
releases.

and we don't branch a release until we start patch releases, 
which of course branch at the  respective tag.
Oct 12 2022
prev sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Oct 13, 2022 at 03:52:57AM +0000, norm via Digitalmars-d wrote:

 On Wednesday, 12 October 2022 at 20:45:43 UTC, H. S. Teoh wrote:


[...]

 Thanks for the tip. (Though I must say, it strikes me as a little
 odd to key the version number off git tags, which are fluid and
 arbitrarily-assigned, as opposed to actual source code that reflects
 the actual functionality behind a particular version number...)




[...]

 Using git tags is quite common in places where I've worked. CI/CD is
 configured to build a release with changelog and release note when it
 sees a semantic version tag arrive.


[...]

 This `v1.2.3-0-gabcd12345` clearly indicates the version, if it is
 actually a release build, and the commit hash, which for us we find
 most important.  One less dereference we have to do when bugs are
 reported.


[...]

It's not so much the usage of git tags for release versioning that I
find odd.  It's the fact that dmd 2.100.2 insists that it's 2.098, sets
`__VERSION__` to 2098L, and believes that it's 2.098, yet the state of
code is clearly already 2.100.2 and the compiler will behave like a
2.100.2 compiler.

In my mind, the state of source code defines the meaning behind the
version number, and therefore the version number ought to be encoded in
the source code, so that the two are consistent.  This is particularly
so in a D compiler where the version number returned by `__VERSION__`
could cause semantic changes in downstream user code (due to static if,
etc.).

Imagine the hypothetical case where 2.100.2 introduced a breaking syntax
change for which user code has to be updated; a user project that wants
to be compilable with both versions of the compiler would likely do
something like:

	static if (__VERSION__ <= 2098L) {
		... // implement feature using 2.098 syntax
	} else {
		... // implement feature using 2.100.2 syntax
	}

In this case, since the compiler thinks it's 2.098, it will compile the
first branch of the static if, but since it's actually a 2.100.2
compiler, it will fail to compile the code that's meant for 2.098. To
add to the confusion, it claims that it's a 2.098 compiler, which will
surely leave users *really* scratching their heads as to what exactly is
going on. :-P


T

-- 
People who are more than casually interested in computers should have at least
some idea of what the underlying hardware is like. Otherwise the programs they
write will be pretty weird. -- D. Knuth
Oct 12 2022
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/13/22 12:16 AM, H. S. Teoh wrote:

 It's not so much the usage of git tags for release versioning that I
 find odd.  It's the fact that dmd 2.100.2 insists that it's 2.098, sets
 `__VERSION__` to 2098L, and believes that it's 2.098, yet the state of
 code is clearly already 2.100.2 and the compiler will behave like a
 2.100.2 compiler.


The build should double check the VERSION file against the tag, and give 
an error when it doesn't match.

-Steve
Oct 13 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Oct 13, 2022 at 10:51:25AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:

 On 10/13/22 12:16 AM, H. S. Teoh wrote:

 It's not so much the usage of git tags for release versioning that I
 find odd.  It's the fact that dmd 2.100.2 insists that it's 2.098,
 sets `__VERSION__` to 2098L, and believes that it's 2.098, yet the
 state of code is clearly already 2.100.2 and the compiler will
 behave like a 2.100.2 compiler.


 
 The build should double check the VERSION file against the tag, and
 give an error when it doesn't match.


+1.


T

-- 
Without geometry, life would be pointless. -- VS
Oct 13 2022
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/13/22 11:19 AM, H. S. Teoh wrote:

 On Thu, Oct 13, 2022 at 10:51:25AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:

 On 10/13/22 12:16 AM, H. S. Teoh wrote:

 It's not so much the usage of git tags for release versioning that I
 find odd.  It's the fact that dmd 2.100.2 insists that it's 2.098,
 sets `__VERSION__` to 2098L, and believes that it's 2.098, yet the
 state of code is clearly already 2.100.2 and the compiler will
 behave like a 2.100.2 compiler.


 The build should double check the VERSION file against the tag, and
 give an error when it doesn't match.


 
 +1.


Looking at this monstrosity, I can't really understand why it's not 
writing the VERSION file anyway:

https://github.com/dlang/dmd/blob/61d7d56a0b82e049f45758bf3b4449fddda2cf96/compiler/src/build.d#L407-L446

Doesn't it seem like it compares the git tag to the text inside VERSION, 
and update VERSION if it's not the same?

-Steve
Oct 13 2022
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Oct 13, 2022 at 11:31:17AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:

 On 10/13/22 11:19 AM, H. S. Teoh wrote:

 On Thu, Oct 13, 2022 at 10:51:25AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:




[...]

 The build should double check the VERSION file against the tag,
 and give an error when it doesn't match.


 
 +1.


 
 Looking at this monstrosity, I can't really understand why it's not
 writing the VERSION file anyway:
 
 https://github.com/dlang/dmd/blob/61d7d56a0b82e049f45758bf3b4449fddda2cf96/compiler/src/build.d#L407-L446
 
 Doesn't it seem like it compares the git tag to the text inside
 VERSION, and update VERSION if it's not the same?


[...]

Hmm.  It doesn't. `contents` is memoized to be either the current git
tag, or the contents of VERSION.  If the git tag doesn't match, then the
contents of VERSION is used instead.  The VERSION build rule then checks
of the contents of VERSION matches `contents` (which at this point, if
there wasn't a git tag, `contents` == the contents of VERSION). Only if
the two differ does VERSION get updated.

So if there is no git tag, VERSION doesn't get updated.


T

-- 
Computers aren't intelligent; they only think they are.
Oct 17 2022
prev sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Wednesday, 12 October 2022 at 20:45:43 UTC, H. S. Teoh wrote:

 Thanks for the tip. (Though I must say, it strikes me as a 
 little odd to key the version number off git tags, which are 
 fluid and arbitrarily-assigned, as opposed to actual source 
 code that reflects the actual functionality behind a particular 
 version number...)


It seems you've had this issue before: 
https://www.digitalmars.com/d/archives/digitalmars/D/DMD_git_master_stuck_
t_2.084_331087.html :D
Oct 12 2022
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Oct 13, 2022 at 05:02:25AM +0000, Max Samukha via Digitalmars-d wrote:

 On Wednesday, 12 October 2022 at 20:45:43 UTC, H. S. Teoh wrote:

 
 Thanks for the tip. (Though I must say, it strikes me as a little
 odd to key the version number off git tags, which are fluid and
 arbitrarily-assigned, as opposed to actual source code that reflects
 the actual functionality behind a particular version number...)


 
 It seems you've had this issue before:
 https://www.digitalmars.com/d/archives/digitalmars/D/DMD_git_master_stuck_at_2.084_331087.html
 :D


LOL... history repeats itself. :-P


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely
repeat each other.
Oct 13 2022