propagating commit hash to vera++ --version output?
hello,
first of all many thanks for bringing python support for rules
to vera. it looks very promising and I am planning to start
using it for real in my projects. I am aware that api may
changed in the future that's why I would like to ask is it possible
to propagate sha1 commit to vera++ --version
output?
currently it gives me only 1.2.1
string so I am not able to distinguish
in easy way different vera++ development versions :(
do you think you could implement such a feature in vera++?
for example it could look like this:
$ ++vera --version
vera++ 1.2.1 (ab231dfa)
or something. for example, blender has similar solution (sorry for large output):
[kaluzka@CNU3099HPJ linux]$ ./blender --version
Color management: using fallback mode for management
Blender 2.71 (sub 3)
build date: 2014-08-02
build time: 07:56:48
build commit date: 2014-08-01
build commit time: 17:08
build hash: 7b83e3d
build platform: Linux:64bit
build type: Release
build c flags: -DWITH_FREESTYLE -pipe -fPIC -funsigned-char -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -fopenmp -DNDEBUG -O2 -DWITH_MOD_FLUID -DWITH_MOD_OCEANSIM -D__LITTLE_ENDIAN__ -DWITH_AUDASPACE -DWITH_AVI -DWITH_OPENNL -DHAVE_STDBOOL_H
build c++ flags: -pipe -fPIC -funsigned-char -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -fopenmp -fpermissive -D__STDC_CONSTANT_MACROS -DNDEBUG -O2 -DWITH_MOD_FLUID -DWITH_MOD_OCEANSIM -D__LITTLE_ENDIAN__ -DWITH_AUDASPACE -DWITH_AVI -DWITH_OPENNL -DHAVE_STDBOOL_H
build link flags: -pthread
build system: SCons
[kaluzka@CNU3099HPJ linux]$
that build hash is actually sha1 for latest commit visible in local repo (after git pull). it is propagated to blender gui itself so I am always able to determine which sources were used for current build. it would be great to have such feature in vera++ too. what do you think about this proposal?
--
Best Regards, Sebastian Kaluzka (skaluzka)
Comments (2)
-
-
reporter that's a good point. I don't have strong opinion about that, but please see below proposals, perhaps some of them could be implemented
1. vera++ built from git sources (working copy not modified):
$ vera++ --version vera++ 1.2.1-dev (a2bdfce4) compilation date: Tue Aug 5 22:04:44 EDT 2014
2. vera++ built from git sources (sources locally modified, not committed):
$ vera++ --version vera++ 1.2.1-dev compilation date: Tue Aug 5 22:04:44 EDT 2014
or
$ vera++ --version vera++ 1.2.1-dev (last commit: a2bdfce4) compilation date: Tue Aug 5 22:04:44 EDT 2014
or
$ vera++ --version vera++ 1.2.1-dev (a2bdfce4 + modifications) compilation date: Tue Aug 5 22:04:44 EDT 2014
or
$ vera++ --version vera++ 1.2.1-dev (based on: a2bdfce4) compilation date: Tue Aug 5 22:04:44 EDT 2014
else ... ;)
3. vera++ built from git sources (modified and committed locally):
$ vera++ --version vera++ 1.2.1-dev (cdeafb21) compilation date: Tue Aug 5 22:04:44 EDT 2014
where cdeafb21 indicates last local commit
4. vera ++ built from pure sources (tar.gz package without .git repository):
$ vera++ --version vera++ 1.2.1-dev compilation date: Tue Aug 5 22:04:44 EDT 2014
5. vera++ new binary/source release (non-development) package:
$ vera++ --version vera++ 1.2.2 compilation date: Tue Aug 5 22:04:44 EDT 2014
- Log in to comment
I like the idea, but I'm not sure what would be the behavior when: * vera++ is built from the tar.gz, thus without any git data * some files are modified in the local repository
Any opinion?