October 13, 2022

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

October 13, 2022
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
October 13, 2022
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.
October 13, 2022

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

October 17, 2022
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.
1 2
Next ›   Last »