The banner is displayed at the start of openbios with the version and build time. This patch adds the revision number for easier identification of binary version. It would look like this:
Welcome to OpenBIOS v1.1 (Revision 1358) built on Nov 28 2015 18:22
If the user doesn't have the svn command, git command, or an svn repo, the word "unknown" is used instead of the number.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
New in revision 3: Added support for a variable length repo number.
New in revision 2: Added support for git if the repo is being managed by it.
Index: Makefile.target =================================================================== --- Makefile.target (revision 1358) +++ Makefile.target (working copy) @@ -52,11 +52,21 @@
versions: $(ODIR)/target/include/openbios-version.h $(ODIR)/forth/version.fs
+# Set the REVISION variable to the current svn revision or to "unknown" +REVISION := $(shell svn info .. | grep "Revision: " | cut -d ' ' -f 2) +ifeq ($(REVISION),) # Try using git to find the revision number + REVISION := $(shell git svn log --oneline -1 | cut -d '|' -f1 | cut -d 'r' -f2 | cut -d ' ' -f 1) +endif +ifeq ($(REVISION),) # if both svn and git failed to find a revision number + REVISION = "unknown" +endif + $(ODIR)/forth/version.fs: $(call quiet-command,true, " GEN $(TARGET_DIR)$@") @DATE="$(shell echo `LC_ALL=C TZ=UTC date +'%b %e %Y %H:%M'`)" ; \ ( echo ": builddate " $$DATE" ; " ; \ - echo ": version " $(VERSION)" ; " ; ) \ + echo ": version " $(VERSION)" ; " ; \ + echo ": revision " $(REVISION)" ; " ; ) \ > $(dir $@)/version.fs
$(ODIR)/target/include/openbios-version.h: @@ -63,7 +73,8 @@ $(call quiet-command,true, " GEN $(TARGET_DIR)$@") @DATE="$(shell echo `LC_ALL=C TZ=UTC date +'%b %e %Y %H:%M'`)" ; \ ( echo "#define OPENBIOS_BUILD_DATE "$$DATE"" ; \ - echo "#define OPENBIOS_VERSION_STR "$(VERSION)"" ; ) \ + echo "#define OPENBIOS_VERSION_STR "$(VERSION)"" ; \ + echo "#define OPENBIOS_REVISION "$(REVISION)"" ; ) \ > $(dir $@)/openbios-version.h
info: Index: forth/admin/banner.fs =================================================================== --- forth/admin/banner.fs (revision 1358) +++ forth/admin/banner.fs (working copy) @@ -9,8 +9,8 @@ ; to builtin-logo
:noname - builddate s" built on " version s" Welcome to OpenBIOS v" pocket - tmpstrcat tmpstrcat tmpstrcat drop + builddate s" ) built on " revision s" (Revision " version s" Welcome to OpenBIOS v" pocket + tmpstrcat tmpstrcat tmpstrcat tmpstrcat tmpstrcat drop ; to builtin-banner
: suppress-banner ( -- )
On Wed, 2 Dec 2015, Programmingkid wrote:
+ifeq ($(REVISION),) # Try using git to find the revision number
- REVISION := $(shell git svn log --oneline -1 | cut -d '|' -f1 | cut -d 'r' -f2 | cut -d ' ' -f 1)
Better but you could cut with separator ' ' right away instead of '|' in the first invocation and then you don't need the third cut. But I think using sed instead of cut could be the simplest here. For example like this:
git svn log --oneline -1 | sed -e 's/^r([0-9]*).*/\1/'
Regards, BALATON Zoltan
On Dec 2, 2015, at 7:06 PM, BALATON Zoltan wrote:
On Wed, 2 Dec 2015, Programmingkid wrote:
+ifeq ($(REVISION),) # Try using git to find the revision number
- REVISION := $(shell git svn log --oneline -1 | cut -d '|' -f1 | cut -d 'r' -f2 | cut -d ' ' -f 1)
Better but you could cut with separator ' ' right away instead of '|' in the first invocation and then you don't need the third cut. But I think using sed instead of cut could be the simplest here. For example like this:
git svn log --oneline -1 | sed -e 's/^r([0-9]*).*/\1/'
Looks like an indecipherable mess.
Goes and tries it out.... OK it does work. If you don't mind, I would prefer to stick with cut. Cut is a lot easier to understand. Regular expressions look like someone just pushed a bunch of random keys on their keyboard.
Mark which do you want to use?
On Wed, 2 Dec 2015, Programmingkid wrote:
On Dec 2, 2015, at 7:06 PM, BALATON Zoltan wrote:
git svn log --oneline -1 | sed -e 's/^r([0-9]*).*/\1/'
Looks like an indecipherable mess.
Goes and tries it out.... OK it does work. If you don't mind, I would prefer to stick with cut. Cut is a lot easier to understand. Regular expressions look like someone just pushed a bunch of random keys on their keyboard.
OK, I have no strong opinion on this but I don't think cut is very portable, sed is much more common. But here's anoter version similar to your cut way just using the shell only if you like:
REVISION="$(git svn log --oneline -1)" && REVISION="${REVISION%% *}" && REVISION="${REVISION#r}" && echo $REVISION
Regards, BALATON Zoltan
On Dec 2, 2015, at 7:34 PM, BALATON Zoltan wrote:
On Wed, 2 Dec 2015, Programmingkid wrote:
On Dec 2, 2015, at 7:06 PM, BALATON Zoltan wrote:
git svn log --oneline -1 | sed -e 's/^r([0-9]*).*/\1/'
Looks like an indecipherable mess.
Goes and tries it out.... OK it does work. If you don't mind, I would prefer to stick with cut. Cut is a lot easier to understand. Regular expressions look like someone just pushed a bunch of random keys on their keyboard.
OK, I have no strong opinion on this but I don't think cut is very portable, sed is much more common. But here's anoter version similar to your cut way just using the shell only if you like:
REVISION="$(git svn log --oneline -1)" && REVISION="${REVISION%% *}" && REVISION="${REVISION#r}" && echo $REVISION
This looks like bash only scripting. I seem to remember Mark not liking the idea of having to use a certain shell. Thank you for this information.
On Wed, Dec 02, 2015 at 07:39:50PM -0500, Programmingkid wrote:
OK, I have no strong opinion on this but I don't think cut is very portable, sed is much more common. But here's anoter version similar to your cut way just using the shell only if you like:
REVISION="$(git svn log --oneline -1)" && REVISION="${REVISION%% *}" && REVISION="${REVISION#r}" && echo $REVISION
This looks like bash only scripting. I seem to remember Mark not liking the idea of having to use a certain shell. Thank you for this information.
"cut" is POSIX. "%%" and "#" are POSIX.
Of course, what you all should be using is svn info | grep 'Last Changed Rev' | awk '{ print $4; }'
(duh).
Segher
On 02/12/15 20:20, Programmingkid wrote:
The banner is displayed at the start of openbios with the version and build time. This patch adds the revision number for easier identification of binary version. It would look like this:
Welcome to OpenBIOS v1.1 (Revision 1358) built on Nov 28 2015 18:22
If the user doesn't have the svn command, git command, or an svn repo, the word "unknown" is used instead of the number.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
New in revision 3: Added support for a variable length repo number.
New in revision 2: Added support for git if the repo is being managed by it.
Hmmmm I'm still not 100% convinced this patch is the right way to go, particularly with git where we have different sets of commit ids depending upon whether you have a local git-svn checkout or a checkout from the (more popular) git.qemu.org.
I'm happy for people who think this would be useful to persuade me otherwise though.
ATB,
Mark.
On Dec 3, 2015, at 5:11 PM, Mark Cave-Ayland wrote:
On 02/12/15 20:20, Programmingkid wrote:
The banner is displayed at the start of openbios with the version and build time. This patch adds the revision number for easier identification of binary version. It would look like this:
Welcome to OpenBIOS v1.1 (Revision 1358) built on Nov 28 2015 18:22
If the user doesn't have the svn command, git command, or an svn repo, the word "unknown" is used instead of the number.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
New in revision 3: Added support for a variable length repo number.
New in revision 2: Added support for git if the repo is being managed by it.
Hmmmm I'm still not 100% convinced this patch is the right way to go, particularly with git where we have different sets of commit ids depending upon whether you have a local git-svn checkout or a checkout from the (more popular) git.qemu.org.
I'm happy for people who think this would be useful to persuade me otherwise though.
Dear Mark, we need a way to tell what version of OpenBIOS we are using. Currently there is no way. The current banner information doesn't tell us enough information to know where it is in the repository. Printing the revision number is something I have seen other open source projects use.
On Dec 3, 2015, at 5:11 PM, Mark Cave-Ayland wrote:
On 02/12/15 20:20, Programmingkid wrote:
The banner is displayed at the start of openbios with the version and build time. This patch adds the revision number for easier identification of binary version. It would look like this:
Welcome to OpenBIOS v1.1 (Revision 1358) built on Nov 28 2015 18:22
If the user doesn't have the svn command, git command, or an svn repo, the word "unknown" is used instead of the number.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
New in revision 3: Added support for a variable length repo number.
New in revision 2: Added support for git if the repo is being managed by it.
Hmmmm I'm still not 100% convinced this patch is the right way to go, particularly with git where we have different sets of commit ids depending upon whether you have a local git-svn checkout or a checkout from the (more popular) git.qemu.org.
I'm happy for people who think this would be useful to persuade me otherwise though.
How would we find out the commit id of OpenBIOS without the patch?
On Dec 3, 2015, at 5:11 PM, Mark Cave-Ayland wrote:
On 02/12/15 20:20, Programmingkid wrote:
The banner is displayed at the start of openbios with the version and build time. This patch adds the revision number for easier identification of binary version. It would look like this:
Welcome to OpenBIOS v1.1 (Revision 1358) built on Nov 28 2015 18:22
If the user doesn't have the svn command, git command, or an svn repo, the word "unknown" is used instead of the number.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
New in revision 3: Added support for a variable length repo number.
New in revision 2: Added support for git if the repo is being managed by it.
Hmmmm I'm still not 100% convinced this patch is the right way to go, particularly with git where we have different sets of commit ids depending upon whether you have a local git-svn checkout or a checkout from the (more popular) git.qemu.org.
Knowing the commit id that the binary is based on is very helpful in determining what features the binary would have. If the new banner text makes you uncomfortable, this patch could be changed so that only the word revision is added to OpenBIOS. I'd be more than happy to make this change if you want. That way the user could still find out the revision their binary is based on.
On 05/12/15 04:13, Programmingkid wrote:
On Dec 3, 2015, at 5:11 PM, Mark Cave-Ayland wrote:
On 02/12/15 20:20, Programmingkid wrote:
The banner is displayed at the start of openbios with the version and build time. This patch adds the revision number for easier identification of binary version. It would look like this:
Welcome to OpenBIOS v1.1 (Revision 1358) built on Nov 28 2015 18:22
If the user doesn't have the svn command, git command, or an svn repo, the word "unknown" is used instead of the number.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
New in revision 3: Added support for a variable length repo number.
New in revision 2: Added support for git if the repo is being managed by it.
Hmmmm I'm still not 100% convinced this patch is the right way to go, particularly with git where we have different sets of commit ids depending upon whether you have a local git-svn checkout or a checkout from the (more popular) git.qemu.org.
Knowing the commit id that the binary is based on is very helpful in determining what features the binary would have. If the new banner text makes you uncomfortable, this patch could be changed so that only the word revision is added to OpenBIOS. I'd be more than happy to make this change if you want. That way the user could still find out the revision their binary is based on.
Right, but remember there are at least 2 different repositories out there with differing git commit ids for each SVN commit so it's not that straightforward.
Note that OpenBIOS is added as a git submodule so we have a snapshot of the tree for each release. For most people, qemu -version or similar will be enough to report what features a particular release will have, and anyone with a checkout of QEMU git can dig in if required. It's also possible to work out the version of QEMU in use from the build date included in the OpenBIOS banner.
For developers/testers then all bets are off as you're going to have a custom binary regardless, so no-one other than the author can track what is in it - which means all you can say is "this is not an official OpenBIOS binary". But then again as mentioned above you can already work this out from the date in the OpenBIOS banner, so then you're back where you started...
ATB,
Mark.
On Dec 5, 2015, at 9:20 AM, Mark Cave-Ayland wrote:
On 05/12/15 04:13, Programmingkid wrote:
On Dec 3, 2015, at 5:11 PM, Mark Cave-Ayland wrote:
On 02/12/15 20:20, Programmingkid wrote:
The banner is displayed at the start of openbios with the version and build time. This patch adds the revision number for easier identification of binary version. It would look like this:
Welcome to OpenBIOS v1.1 (Revision 1358) built on Nov 28 2015 18:22
If the user doesn't have the svn command, git command, or an svn repo, the word "unknown" is used instead of the number.
Signed-off-by: John Arbuckle programmingkidx@gmail.com
New in revision 3: Added support for a variable length repo number.
New in revision 2: Added support for git if the repo is being managed by it.
Hmmmm I'm still not 100% convinced this patch is the right way to go, particularly with git where we have different sets of commit ids depending upon whether you have a local git-svn checkout or a checkout from the (more popular) git.qemu.org.
Knowing the commit id that the binary is based on is very helpful in determining what features the binary would have. If the new banner text makes you uncomfortable, this patch could be changed so that only the word revision is added to OpenBIOS. I'd be more than happy to make this change if you want. That way the user could still find out the revision their binary is based on.
Right, but remember there are at least 2 different repositories out there with differing git commit ids for each SVN commit so it's not that straightforward.
Note that OpenBIOS is added as a git submodule so we have a snapshot of the tree for each release. For most people, qemu -version or similar will be enough to report what features a particular release will have, and anyone with a checkout of QEMU git can dig in if required. It's also possible to work out the version of QEMU in use from the build date included in the OpenBIOS banner.
For developers/testers then all bets are off as you're going to have a custom binary regardless, so no-one other than the author can track what is in it - which means all you can say is "this is not an official OpenBIOS binary". But then again as mentioned above you can already work this out from the date in the OpenBIOS banner, so then you're back where you started...
Ok. I understand. Could we have a version 1.2 of OpenBIOS soon. There has been a lot of progress with making Mac OS 9 boot in QEMU. The only thing left is figuring out why programs like the Control Strip module crash. My theory is the PowerPC emulation is buggy for a few instructions.
-
BALATON Zoltan -
Mark Cave-Ayland -
Programmingkid -
Segher Boessenkool