fix version

[jp-embedded]

scxmlcc version should be generated equally on windows/linux with make and cmake

note from pull request 55:
Well the version is/should be the same on windows and unix. The thing is, the autorevision tool is currently not used on windows and therefore the postfix part of the version is currently left out on windows (in version.cpp) - I am mainly using linux. If it is possible to use the autorevision tool on windows I think that would be the best solution since autorevision is a more generic way of doing it. Anyway, the goal must be to use the same method on windows/unix/make/cmake. Note that the current method will work also when build from a zip file or even if the source is checked out using subversion.

[jp-embedded]

note from PR:

Yes, I think that is better. However:

The original versioning idea was to add the postfix like this (from makerevision.sh):

• if not on version control (code downloaded from zip): no postfix

• if on master branch: use -$VCS_TICK, if not 0

• otherwise: Use '-$FULL_HASH'

• add M if locally modified

so if the base version is e.g. 1.14, the printed version is "1.14" if:

the source is build out of source control - e.g. from a downloaded zip/gz file.
the source is cloned by git/svn, is on master/trunk branch, and there is no commits since last tag and no local modifications
if there is e.g. 3 commits since last tag, the build is no longer equal to 1.14, so add '-3' postfix, resulting in version "1.14-3".

This will be the versions shown for most users of scxmlcc (non developers) "1.14" for a tagged clone or zip/gz download, and "1.14-3" if latest master is cloned.

if not on master branch, it is a 'developer clone'. This can't be described with a simple number, so add full hash, e.g. "1.14-sn34h454s32h5s34hh5s4325"

if there are local modifications, add 'M' postfix to describe the build is modified. e.g. "1.14M" or "1.14M-3"

This is what makerevision.sh does. It may be a bit complicated, but it is the best non-manual method I could come up with to distinguish different versions. The only manual thing to do with this setup is to update the base version when tagging.

[aboseley]

Hi Jan, You've got some very specific ideas on how you want this to work, so I may as well just run the original make rule. See #60, for another attempt. Adam

…

On Mon, May 21, 2018 at 10:52 PM, Jan Pedersen ***@***.***> wrote: note from PR: Yes, I think that is better. However: The original versioning idea was to add the postfix like this (from makerevision.sh): - if not on version control (code downloaded from zip): no postfix - if on master branch: use -$VCS_TICK, if not 0 - otherwise: Use '-$FULL_HASH' - add M if locally modified so if the base version is e.g. 1.14, the printed version is "1.14" if: the source is build out of source control - e.g. from a downloaded zip/gz file. the source is cloned by git/svn, is on master/trunk branch, and there is no commits since last tag and no local modifications if there is e.g. 3 commits since last tag, the build is no longer equal to 1.14, so add '-3' postfix, resulting in version "1.14-3". This will be the versions shown for most users of scxmlcc (non developers) "1.14" for a tagged clone or zip/gz download, and "1.14-3" if latest master is cloned. if not on master branch, it is a 'developer clone'. This can't be described with a simple number, so add full hash, e.g. "1.14- sn34h454s32h5s34hh5s4325" if there are local modifications, add 'M' postfix to describe the build is modified. e.g. "1.14M" or "1.14M-3" This is what makerevision.sh does. It may be a bit complicated, but it is the best non-manual method I could come up with to distinguish different versions. The only manual thing to do with this setup is to update the base version when tagging. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AM4QV-OaqytCnKoH7GAmyRaPDgSUjsuXks5t0riggaJpZM4T9UQN> .

[jp-embedded]

With #60, auto versioning now works the same way on make & cmake
Now, it just needs to be implemented on windows also some day...