Similar to Incorrect version number in built version, my local builds are again showing as version 102.1 rather than 103.0, despite OpenChemistry, avogadroapp, and avogadrolibs all being up-to-date.
Any idea why/how to fix it?
Similar to Incorrect version number in built version, my local builds are again showing as version 102.1 rather than 103.0, despite OpenChemistry, avogadroapp, and avogadrolibs all being up-to-date.
Any idea why/how to fix it?
I believe it’s cached in your CMake files. I don’t know if there’s a great way to fix it beyond blowing away your build directories, but I haven’t bothered to look for solutions either.
I regularly completely remove my build directory and build completely from fresh, i.e.
$ ls
avogenerators/ openchemistry/ plugins/ two.avogadro.cc/
avo-plugin-demo/ org.openchemistry.Avogadro2/ build/
$ rm -rf ./build
$ ls
avogenerators/ openchemistry/ plugins/ two.avogadro.cc/
avo-plugin-demo/ org.openchemistry.Avogadro2/
$ cmake -DBUILD_MOLEQUEUE=OFF -DUSE_PLOTTER=OFF -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -S ./openchemistry -B ./build
$ cmake --build ./build -j 10
Is that what you mean by blowing away my build directories? Because that doesn’t solve the issue. It didn’t back in 2024 either, so I think it must be something else.
The avogadrolibs version is also just not correct, when shown both in the GUI and in the terminal.
What on the other hand does show the correct version is the final line of the launch output:
❯ ./build/prefix/bin/avogadro2
Avogadroapp version: 1.102.1-234-g140923f
Avogadrolibs version: 1.102.1-740-g41008c0d
Qt version: 6.10.2
qt.core.qobject.connect: QObject::connect(QObject, Unknown): invalid nullptr parameter
SSL version: "OpenSSL 3.5.3 16 Sep 2025"
Using locale: "en_GB"
qt Translation successfully loaded.
AvogadroApp Translation "en_GB" loaded "/home/matt/avo/build/prefix/bin/../share/avogadro2/i18n/"
AvogadroLibs Translation "en_GB" loaded "/home/matt/avo/build/prefix/bin/../share/avogadro2/i18n/"
Extension plugins dynamically found… 45
registering obmm plugins
OBProcess::executeObabel: Running "/home/matt/avo/build/prefix/bin/obabel" "-L formats read"
...
"/home/matt/avo/build/prefix/bin/obabel" found: "/home/matt/avo/build/prefix/bin/obabel: Open Babel 3.1.1 -- Mar 7 2026 -- 02:57:43"
Checking for packages in "/home/matt/.local/share/OpenChemistry/Avogadro/plugins"
...
Load registered packages
RPC server listening on: "/tmp/avogadro"
Open Babel formats ready: 142
Setting default format to cjson.
update comparing "1.103.0" to "1.103.0"
Note that the actual avogadrolibs commit used was 41008c0d19afce283aacb65be86d2eedd7e46f1e, and for avogadroapp 140923f41ed9cc3dd2af1cd9fd37cee77444cbd5.
Do you have a cmake file like AvogadroLibsConfig.cmake in your system directories from a “make install” or something? Might also be a system-level <avogadro/version.h>
I’m not a Cmake expert, but the versions are set by cmake and compiled in.
It seems the same thing happens with both avogadroapp and avogadrolibs, and it’s the former that actually results in the overall Avogadro version being wrong (which I guess makes sense).
The really weird thing is that switching from my recently merged menu-paths branch to the latest master fixes it. For both libs and app. I can even use a combination of master of one and menu-paths for the other and get a mixture of 1.103.0 and 1.102.1.
Thing is, I never made any changes in my menu-paths branch of avogadroapp, so it should be identical to master at 140923f41ed9cc3dd2af1cd9fd37cee77444cbd5. This is despite the fact that git diff master and git diff upstream/master show no changes to anything that might remotely influence these things. And surely switching branches wouldn’t change anything that doesn’t show up with git diff…
Edit: OK it’s not as simple as that because now somehow that behaviour isn’t reproducible and now it’s stuck as always incorrect. Who knows what’s going on to be honest ![]()
OK, it was a Git issue (or more accurately, a failure on my part to use Git correctly). I just hadn’t been fetching all the tags before/while pulling, so the output of git describe was wrong, and that’s what the CMake uses to define the version number. Hope this helps anyone who has the same issue in future!