Invalid V version with build for 0.5 release

[lcheylus]

I'm trying to package V 0.5 release for Debian/Linux, building it from release sources (not from sources from Git repository).

In this case, the V version output is invalid:

$ ./v version
V 0.5.0 e2f5d6c

=> a short hash for is displayed. Since commit adbc802, that should no longer be the case. The correct V version displayed must be V 0.5.0 (without hash).

Steps to reproduce this issue with release 0.5

• Download sources for V 0.5 et corresponding vlang/vc (commit vlang/vc@294bff4)
• Link /usr/lib/x86_64-linux-gnu/libgc.a for thirdparty/tcc/lib/libgc.a
• Build from sources with make local=1 prod=1 (compiler = Clang on Debian Linux/amd64)

$ wget https://github.com/vlang/v/archive/refs/tags/0.5.tar.gz -O v-0.5.0.tar.gz
$ wget https://github.com/vlang/vc/archive/294bff4ef87427743d0b35c0f7eb1b34a6dd061b.tar.gz -O vc-294bff4ef87427743d0b35c0f7eb1b34a6dd061b.tar.gz
$ tar xzvf v-0.5.0.tar.gz

$ cd v-0.5
$ mv -v ../vc-294bff4ef87427743d0b35c0f7eb1b34a6dd061b ./vc

$ mkdir -p thirdparty/tcc/lib/
$ ln -s /usr/lib/x86_64-linux-gnu/libgc.a thirdparty/tcc/lib/libgc.a

$ make local=1 prod=1
Using local vc
Using local tcc
The executable './thirdparty/tcc/tcc.exe' does not work.
cc  -std=gnu99 -w -o v1 ./vc/v.c -lm -lpthread  || cmd/tools/cc_compilation_failed_non_windows.sh
./v1 -no-parallel -o v2 -prod cmd/v
./v2 -nocache -o ./v -prod cmd/v
rm -rf v1 v2

Note: `tcc` was not used, so unless you install it yourself, your backend
C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`.

These C compilers, are several times slower at compiling C source code,
compared to `tcc`. They do produce more optimised executables, but that
is done at the cost of compilation speed.

V has been successfully built
V 0.5.0 e2f5d6c

No issue with V 0.4.12 release: the V version displayed is correct, no short hash in output.

$ ./v version
V 0.4.12

Steps to rebuild V for release 0.4.12

• Download sources for V 0.4.12 et corresponding vlang/vc (commit vlang/vc@e377b42)
• Link /usr/lib/x86_64-linux-gnu/libgc.a for thirdparty/tcc/lib/libgc.a
• Build from sources with make local=1 prod=1 (compiler = Clang on Debian Linux/amd64)

$ wget https://github.com/vlang/v/archive/refs/tags/0.4.12.tar.gz -O v-0.4.12.tar.gz
$ wget https://github.com/vlang/vc/archive/e377b42e26eb9c703ccaf65f37d700a7369ac3db.tar.gz -O vc-e377b42e26eb9c703ccaf65f37d700a7369ac3db.tar.gz
$ tar xzvf v-0.4.12.tar.gz

$ cd v-0.4.12
$ mv -v ../vc-e377b42e26eb9c703ccaf65f37d700a7369ac3db ./vc

$ mkdir -p thirdparty/tcc/lib/
$ ln -s /usr/lib/x86_64-linux-gnu/libgc.a thirdparty/tcc/lib/libgc.a

$ make local=1 prod=1
Using local vc
Using local tcc
The executable './thirdparty/tcc/tcc.exe' does not work.
cc  -std=gnu99 -w -o v1 ./vc/v.c -lm -lpthread  || cmd/tools/cc_compilation_failed_non_windows.sh
./v1 -no-parallel -o v2 -prod cmd/v
./v2 -nocache -o ./v -prod cmd/v
rm -rf v1 v2

Note: `tcc` was not used, so unless you install it yourself, your backend
C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`.

These C compilers, are several times slower at compiling C source code,
compared to `tcc`. They do produce more optimised executables, but that
is done at the cost of compilation speed.

V has been successfully built
V 0.4.12

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[lcheylus]

During debug of this issue, I don't find/understand why @VCURRENTHASH is defined in sources for 0.5 release => these sources are not in a Git repository, this value must not be defined.

VCURRENTHASH is defined in V 0.5 release

$ ./v version
V 0.5.0 e2f5d6c

$ echo "println('VCURRENTHASH=\${@VCURRENTHASH}')" | ./v run -
VCURRENTHASH=e2f5d6c

With V 0.4.12 release, VCURRENTHASH is not defined:

$ ./v version
V 0.4.12

$ echo "println('VCURRENTHASH=\${@VCURRENTHASH}')" | ./v run -
VCURRENTHASH=

I didn't find where @VCURRENTHASH variable is set in V sources.

[JalonSolov]

In the CHANGELOG for V, the latest mention of VCURRENTHASH I see is for V 0.4.11 (which means it existed before that):

v.util.version: fix output for V full version when VCURRENTHASH not defined (#24264)

So you should have been getting the hash for 0.4.12, unless you somehow hit a similar bug where it was undefined, but was fixed by the 0.5.0 release.

From my own personal experience, I have never seen v version output without a hash.

[lcheylus]

In the CHANGELOG for V, the latest mention of VCURRENTHASH I see is for V 0.4.11 (which means it existed before that):

v.util.version: fix output for V full version when VCURRENTHASH not defined (#24264)

I know that, I'm the author of this modification, commit adbc802 See issue #24263 for detailed explanations.

So you should have been getting the hash for 0.4.12, unless you somehow hit a similar bug where it was undefined, but was fixed by the 0.5.0 release.

No, see my explanations above when building V 0.4.12 from release sources => in this case VCURRENTHASH is not defined.
There is a difference in generation of release sources between V 0.4.12 and V 0.5: for the 0.5 case, VCURRENTHASH is defined in release sources. But I don't find why...

From my own personal experience, I have never seen v version output without a hash.

It's "normal" if you've never rebuilt V from release sources (version >= 0.4.11) but only from the Git repository.

[JalonSolov]

By "release sources", I'm guessing you mean from the ZIP files that are created? Yeah, those don't have a .git subdir as you would with a clone, so finding a hash would be problematic.

I have said, many times over the years, that V is not ready for an official "release", official packages, etc. It may not be ready before v1.0.

[lcheylus]

I have said, many times over the years, that V is not ready for an official "release", official packages, etc. It may not be ready before v1.0.

I disagree: if we want V to be more used and known, it must be packaged and available for the main Linux distributions and via BSD ports, even for versions < v1.0. Otherwise there's no point in making announcements for each new version.

Anyway, V is already packaged for many systems, see this list on Repology https://repology.org/project/vlang/versions

[lcheylus]

By "release sources", I'm guessing you mean from the ZIP files that are created? Yeah, those don't have a .git subdir as you would with a clone, so finding a hash would be problematic.

Do you read my detailed explanations before trying to help me and answer? I think that my initial report for this issue is enough clear...

$ wget https://github.com/vlang/v/archive/refs/tags/0.5.tar.gz -O v-0.5.0.tar.gz

[JalonSolov]

No need to get so worked up. That's still just an archive of current sources, not an official "release" of V. It also doesn't have a .git subdir, same as the ZIP files, as it's just an alternative archive of the same files.

No .git == no hash.

It's possible the hash is "baked into" the code now, as of the time the archive is made, which would explain why it shows up for the 0.5.0 source archive you're pulling.

However, I agree about not being able to find where it's being set.

Perhaps @spytheman knows.

[lcheylus]

An archive of current sources, built from an official Git tag == "a release" as defined by GitHub and every OSS project for decades. No need to quibble over wording.

[jorgeluismireles]

IMHO V's versioning still is just a simply a chain of updates. V0.5.0 follows V0.4.12 but never will be a 0.4.13 in parallel with 0.5.0 to "fix" contracts on 0.4.x "series". Also the repository has a single branch and a new numbers are assigned after sufficient weekly tags around half a year. The doc of every version includes a lot of information.

This simplicity is OK, since at every point you can run v up and get the latest commit (including regressions) but using git tools you can go back in need. From the beginning was told last version should be 1.0 and they talked about decades. Seems to me we should forget 0.4.x and the older.

[spytheman]

@lcheylus the root cause of the difference, between the old behavior and the current one is this piece of code in checker.v:

    v_current_commit_hash := if pref_.building_v {
        version.githash(pref_.vroot) or { vcurrent_hash() }
    } else {
        vcurrent_hash()
    }

which for 0.4.12 generated a buggy C snippet:

    string _t2; /* if prepend */
    if (pref_->building_v) {
        _result_string _t3 = v__util__version__githash(pref_->vroot);
        if (_t3.is_error) {
            builtin__vcurrent_hash();
        }
        _t2 = (*(string*)_t3.data);
    } else {
        _t2 = builtin__vcurrent_hash();
    }
    string v_current_commit_hash = _t2;

note, how in the middle, the result of builtin__vcurrent_hash(); is not assigned to anything in the inner most if (_t3.is_error) { check -> v_current_commit_hash becomes '' by accident ,
which later means that @VCURRENTHASH will also be substituted with '', and the later stages of v (the bootstrapped ones after the cc compilation), will have '' in the second part of the version -> the observed V 0.4.12 .

In 0.5, the code generation was fixed, and now the above snippet leads to this C code for it:

   string _t2; /* if prepend */
    if (pref_->building_v) {
        _result_string _t4 = v__util__version__githash(pref_->vroot);
        if (_t4.is_error) {
            *(string*) _t4.data = builtin__vcurrent_hash();
        }
        _t2 = (*(string*)_t4.data);
        goto _t3;
    };
    {
        _t2 = builtin__vcurrent_hash();
    }
    _t3: {};
    string v_current_commit_hash = _t2;

which now, correctly reflects the intent of the V original -> v_current_commit_hash becomes the hash, inherited from the v.c version -> @VCURRENTHASH is also != '', even after bootstrapping -> the observed V 0.5.0 e2f5d6c .

To keep the consequences of the old behavior (i.e. setting the hash to '', when there is no .git metadata from the repository), the above V code should become:

    v_current_commit_hash := if pref_.building_v {
        version.githash(pref_.vroot) or { '' }
    } else {
        vcurrent_hash()
    }

[JalonSolov]

IMO, the old code was in error, and the current is correct. It should have always shown the hash, and should continue to do so until V is ready for an actual numbered release.

At that point, the hash should only show if -v is added to v version.

[spytheman]

The V code is the same, it is the generated C code that leads to the observed difference.

The V code should be changed, to reflect the intent of the developers, and then the already non buggy C code will also work, this time not as a result of a bug, but by intention.

[spytheman]

The documented intent of @VCURRENTHASH is to have the git hash of the compiler. That is available, when V is built from source in its git repo. It is not available, when it is built outside of it, and it should be '' in that case.

[spytheman]

TLDR: Using version.githash(pref_.vroot) or { vcurrent_hash() } makes @VCURRENTHASH "stuck" to the last value that it had, when the corresponding v.c file was generated. In 0.4.12 that was buggy, but the observed effect was the same as the desired one, thus it was not discovered then.

We should use version.githash(pref_.vroot) or { '' } instead .