FreeEMS Issues - Tunix
View Issue Details
0000321TunixBuild Systempublic2011-10-18 15:422012-02-22 14:35
0000321: Make a distinction between release builds and normal builds.
Release builds are only done once a month or year or two, and as such it's reasonable to put a bit of extra work in to brand the release with it's version number and/or name. For all of the dev versions it should be promimently displayed somewhere, if using a snapshot scheme, then 0.9.24-SNAPSHOT should be the version, however it would be nice to integrate the current git hash into the app in an about box or similar for all builds too. See 0000257 for more info on that, or just google it :-)
No tags attached.
? config.h (4,376) 2011-10-24 18:33

2011-10-18 22:29   
Done in commit 47fc9f
2011-10-23 16:06   
Still waiting for fred to close this
2011-10-24 10:00   
96f4f8 worked correctly on Linux with the full snapshot version showing in the title and in the about window including the hash making it very straight forward to see that I was on the wrong version (because I forgot to sudo make install) after seeing a different hash in the autofoo output from the mac that I had just updated. However the latest version doesn't do that in either normal or debug builds, if you took it out on purpose, please put it back. The mac doesn't work at all, though: [^]

If you need more info, just ask, happy to help on either platform. I might even fire up Isa's Spanish win laptop and try out that build you did for me on that too! :-)
2011-10-24 14:19   
stupid mac linefeed chars. OK, I'll have to fix that later with some tr magic...
2011-10-24 14:23   
Note it stopped working on Linux since your initial work too. Maybe you missed that in the long winded comment, maybe not. Just making sure.
2011-10-24 14:53   
broke WHERE exactly ? i.e. what is wrong?
2011-10-24 14:54   
If you failed to run "./" that would explain a lot of it. That is standard procedure for "what to do" after pulling updates from version control

even the contrib/update script I made for you do that.
2011-10-24 17:12   
Nope, I did a "FredMake clean" IE, rm -rf *;git reset --hard HEAD, then, which I STATED above :-) I did it with and without debug... then make, sudo make install, and execute binary in another terminal.

The older version just after your initial work worked as required/desired and the newer ones don't seem to. I can retry if you're sure it works fine. Try a Fred-spec clean on yours in case autofoo is cocking something up, maybe?
2011-10-24 17:20   
Shit... fail. I forgot to merge/ff your stuff after i reset it back to before the merge... damn it. Retrying now. Ignore previous message.
2011-10-24 17:33   
I retract the apology, although I had forgotten to get the latest on the last try, the previous tries I had done it right, as I just checked and got this output. Does the sed error mean anything much? The app doesn't have the snapshot/git stuff in the title or about box anymore. It did in other revisions between when you made the change and now, though. And I was super excited and happy with you when I saw it. And now slightly sad that it's gone again :-(

config.status: config.h is unchanged
config.status: executing depfiles commands
sed: -e expression 0000001, char 24: unknown option to `s'
config.status: executing libtool commands
config.status: executing default-1 commands
config.status: executing po/stamp-it commands

MegaTunix 0.9.24-SNAPSHOT_731381 Configuration:

    Install Path: /usr/local
    General Debugging: no
    Allow Deprecated functions: no
    Profiling: no

Now type `make' to compile.
2011-10-24 17:33   
Excuse mantis stealing your hash 1 and turning it into a link...
2011-10-24 17:50   
2011-10-24 18:33   
Attaching mac config.h as requested.
2011-10-24 18:39   
Try now, seems make doesn't support "echo -n" syntax (-n for no newline)
2011-10-24 22:02   
Tested, grepped, etc, works GREAT!!! I LOVE it!!! :-)
2011-12-02 11:00   
Sorry to reopen this, but I've noticed something funky about it and also have a suggestion for improving it a little.

The issue is that the git version gets resolved during the run, not the make run. This is bad because it labels the gui with whenever the last autogen was, not whenever the last build was. IE, right now my MTX claims to be older than it really is. This is confusing and could cause support problems, even with other devs like me :-)

Secondly, if you use git describe like so:

fred@cheetah:~/MegaTunix$ git describe --dirty=-CUSTOM

Then you automatically get a well formatted string to use. My technique in the firmware is to tag the version after a release with, in your case, 0.9.24-SNAPSHOT such that git describe would come back with

0.9.24-SNAPSHOT-<number of commits since tag>-g<hash> [-CUSTOM custom suffix only if git status returns unclean.]

If you do it this way, it automatically works correctly during development and at release time. During release you'll get the repo ready, test it, clean it, tag it, build it, distribute it. Due to being ON the tag at that point the describe will simply return 0.9.24 with no suffix, perfect for the gui, once again :-)

I'm going to open a new issue on tags as I have some advice and spotted an issue.
2011-12-29 18:56   
I don't understand this nor how to do what I think you're asking. Please be more descriptive as to the actual problem and the method of solving it in step form.
2012-02-21 03:48   
please re-evaluate this. The internal version on the about page should reflect the current hash.
2012-02-22 14:35   
Fixed in 765d15864dca998915cb8bc1d23629cb7ebe95b9