PPSSPP git version doesn't update under rare circumstances

[pal1000]

This began happening after the project files were permanently upgraded to VS2013 (2c204e8). Last time it happened when upgraded the source from v0.9.7.2-92-gafdaaf3 to v0.9.7.2-95-g99283b0 using msysgit, built and surprisingly version didn't change in the executable, I had to rebuild to sort it out. I don't know what's going on. It didn't happen again since then.

[solarmystic]

It actually happens at times using Git Bash too, even before the move to VS2013.

When that happens I just run the git-version-gen.cmd file in the Windows subfolder of the ppsspp project directory that forces a git version update which resolves the issue for that particular instance when compiling PPSSPP for Windows.

[unknownbrackets]

I don't think I've ever seen it not update. Maybe if nothing in Core is changed in 2013?

You can try bisecting or etc. - it should update every time.

-[Unknown]

[pal1000]

It happened again after updating source from v0.9.7.2-220-ge11e4cf to v0.9.7.2-221-g505b0c3. Most likely because it's a very small change, Core project didn't get updated. It's reference didn't appear at all in the building log.
I used @solarmystic's suggested workaround and worked surprisingly. It also suppressed #5030 at the same time which occurred exception-less since v0.9.7.2-57-g4e93573. Could these 2 issues be related, or it's just a coincidence, I don't know.

[hrydgard]

Still an issue?

[pal1000]

I followed @solarmystic guideline and worked around it since March. But, I'll retest, though this will require plenty of time and small commits that don't interact with Core project. Anyway testing is on. I disabled the workaround.
Update: I was completely wrong about this being related to #5030. If you have more stuff in the Homebrews and demos storage, the more unrelated these issues become. Back then I was having few stuff in there.

[pal1000]

Yes, @hrydgard, this issue can still be reproduced with msysgit and Visual Studio 2013 Update 3.
I managed to reproduce by upgrading source from v0.9.9.1-90-g 2eafb09 to v0.9.9.1-91-g dae07e9 which is a small change that doesn't contain anything close to the Core project. Version in PPSSPP didn't keep up, no file from core project has been processed by Visual Studio during build process. It should have been one, git-version.cpp. If I recall it only built 2 projects, but Core was not among them.
After this I downgraded source to v0.9.9.1-89-g0702861 and tested again, and guess what, because this is also a small change unrelated to Core project, in reverse of course, it led to a similar buggy behavior, PPSSPP version still remained at v0.9.9.1-90-g 2eafb09 . If I recall correctly Visual Studio built the following projects during the downgrade test: native, UI,UnitTest, PPSSPPHeadless, PPSSPPWindows. Obviously no mention to Core.
The only workaround is to ensure that Windows\git-version-gen.cmd runs every time before building PPSSPP as @solarmystic advised me a couple of months ago. The workaround forces git-version.cpp to update This file seams to be the cause of this issue, yes, it is stuck at v0.9.9.1-90-g 2eafb09 as well.
The bug appears to be in git-version.cpp file functionality because this file content doesn't update if Visual Studio has nothing else to process from Core project.

Update from any revision to v0.9.9.1-92-g d4ec7d8 succeeds with no issue because MIPSAnalyst.cpp is part of Core project.

[pal1000]

Another case. Updating from v0.9.9.1-118-g 64100dc to v0.9.9.1-128-g caa34c4 leads to another reproduction of this issue. These commits only changed files of GPU project. Visual Studio only built GPU, PPSSPPHeadless, UnitTest and PPSSPPWindows.

[vnctdj]

I have just encountered this issue while I was updating to 4c06232, my PPSSPP build was keeping the previous version number I used (from ff68e32).

I have added the execution of the git-version-gen.cmd file in my bash script, just to be sure :)
Thank you for the tip @solarmystic !

[unknownbrackets]

Probably can just add the build rule to GPU, Common, and Windows, or etc. I don't want to see it like Dolphin where the build is always dirty, that's annoying.

-[Unknown]

[unknownbrackets]

Personally, I don't think it's worth making this update any more than bafa7d0 makes it.

The following are the remaining scenarios:

• native, armips, ffmpeg, or a submodule is updated.
• assets are changed (e.g. graphics or etc.)
• intentionally not when UnitTest or Headless is changed only.

Assets aren't really code changes, especially since they are not in the executable on Windows.

Triggering on the submodules isn't really reasonable without triggering a script even when not dirty, which I think marks the build as always dirty in Visual Studio (as I mentioned above, I find this very annoying, and I sometimes want to start without recompiling.)

Anyway, the goal of the version update, at least from my perspective, isn't so much private dev builds as buildbot builds. This problem doesn't affect the buildbot, because for better or for worse (probably for better), it does a clean build every time. That means the builds on the download page always have the latest version, for all platforms.

-[Unknown]

[pal1000]

It happened again after this update: 3706414...2e675c7.

[unknownbrackets]

In that case, building UI will make Core dirty, and if you build again it will update. Again, I think that it's not worth making the build constantly dirty.

-[Unknown]

[hrydgard]

This issue still exists, I believe, and is a small annoyance sometimes.

[unknownbrackets]

It feels like MSVC has made it so the build is constantly dirty now anyway (because of file watches detecting access to git-version.cpp), I don't think I've really seen the build number not get updated unless changing something like libzstd only. Maybe there's some other way we can do this, maybe moving it to a prebuild step of some project everything is dependent on...

-[Unknown]