Re: Getting the CVS revision of Zsh

Re: Getting the CVS revision of Zsh

[Peter Stephenson]

On Fri, 9 Jan 2009 14:07:27 +0100
"Richard Hartmann" <richih.mailinglist@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 13:58, Peter Stephenson <pws@csr.com> wrote:
> 
> > Hmm... yes, grepping an $Id$ out of ChangeLog, which should always be
> > present, ought to be good enough.  It probably needs to be added at the
> > end.  That's considerably simpler.
> 
> The docs[1] tell me there is a $Revision$

(Move to workers.)

I've already committed a ChangeLog with the revision in.  Using this
appears to be straightforward...

Index: Doc/Zsh/params.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/params.yo,v
retrieving revision 1.49
diff -u -r1.49 params.yo
--- Doc/Zsh/params.yo	5 Sep 2008 21:02:13 -0000	1.49
+++ Doc/Zsh/params.yo	9 Jan 2009 20:10:51 -0000
@@ -727,6 +727,14 @@
 Expands to the basename of the command used to invoke this instance
 of zsh.
 )
+vindex(ZSH_PATCHLEVEL)
+item(tt(ZSH_PATCHLEVEL))(
+The revision string for the version number of the ChangeLog file
+in the zsh distribution.  This is most useful in order to keep
+track of versions of the shell during development between releases;
+hence most users should not use it and should instead rely on
+tt($ZSH_VERSION).
+)
 item(tt(zsh_scheduled_events))(
 See ifzman(the section `The zsh/sched Module' in zmanref(zshmodules))\
 ifnzman(noderef(The zsh/sched Module)).
@@ -740,7 +748,7 @@
 )
 vindex(ZSH_VERSION)
 item(tt(ZSH_VERSION))(
-The version number of this zsh.
+The version number of the release of zsh.
 )
 enditem()
 texinode(Parameters Used By The Shell)()(Parameters Set By The Shell)(Parameters)
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.151
diff -u -r1.151 params.c
--- Src/params.c	8 Jan 2009 13:12:09 -0000	1.151
+++ Src/params.c	9 Jan 2009 20:10:55 -0000
@@ -31,6 +31,7 @@
 #include "params.pro"
 
 #include "version.h"
+#include "patchlevel.h"
 
 /* what level of localness we are at */
  
@@ -748,6 +749,7 @@
     setsparam("VENDOR", ztrdup(VENDOR));
     setsparam("ZSH_NAME", ztrdup(zsh_name));
     setsparam("ZSH_VERSION", ztrdup(ZSH_VERSION));
+    setsparam("ZSH_PATCHLEVEL", ztrdup(ZSH_PATCHLEVEL));
     setaparam("signals", sigptr = zalloc((SIGCOUNT+4) * sizeof(char *)));
     for (t = sigs; (*sigptr++ = ztrdup(*t++)); );
 
Index: Src/zsh.mdd
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.mdd,v
retrieving revision 1.18
diff -u -r1.18 zsh.mdd
--- Src/zsh.mdd	19 Sep 2008 12:58:54 -0000	1.18
+++ Src/zsh.mdd	9 Jan 2009 20:10:55 -0000
@@ -33,12 +33,21 @@
 
 init.o params.o parse.o: version.h
 
+params.o: patchlevel.h
+
 # The main shell doesn't currently need zshcurses.h and zshterm.h,
 # but make sure these are built with the headers.
 # If it did need need them they would be in headers at the top instead.
 version.h: $(sdir_top)/Config/version.mk zshcurses.h zshterm.h
 	echo '#define ZSH_VERSION "'$(VERSION)'"' > $@
 
+patchlevel.h: $(sdir_top)/ChangeLog
+	{ \
+	  echo -n "#define ZSH_PATCHLEVEL "; \
+	  sed -ne 's/^\* *\$$Revision: \(.*\) \$$/"\1"/p' \
+	  $(sdir_top)/ChangeLog; \
+	} >patchlevel.h
+
 zshcurses.h: ../config.h
 	@if test x$(ZSH_CURSES_H) != x; then \
 	  echo "#include <$(ZSH_CURSES_H)>" >zshcurses.h; \


-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Getting the CVS revision of Zsh

[Richard Hartmann]

On Fri, Jan 9, 2009 at 21:13, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:

> I've already committed a ChangeLog with the revision in.  Using this
> appears to be straightforward...

Thanks.


> +hence most users should not use it and should instead rely on
> +tt($ZSH_VERSION).

"should rely on tt($ZSH_VERSION), instead." sounds better to
me, but keep in mind i am not a native speaker. Drop the comma
if you want to, people keep telling me we foreigners use too many
of them, anyway :p


Richard

Re: Getting the CVS revision of Zsh

[Peter Stephenson]

On Fri, 9 Jan 2009 23:33:55 +0100
"Richard Hartmann" <richih.mailinglist@gmail.com> wrote:
> > +hence most users should not use it and should instead rely on
> > +tt($ZSH_VERSION).
> 
> "should rely on tt($ZSH_VERSION), instead." sounds better to
> me, but keep in mind i am not a native speaker.

Since you're interested: "should instead" is slightly more formal
phrasing, although from the point of view of sense there's nothing much
in it.  The comma before an adverb would be non-standard, but the same
comment applies.  The tendency among native speakers nowadays appears to
be to underuse commas---none of these things are quite as absolute as
people have sometimes liked to claim, although nowadays people sometimes
go to the opposite extreme.  In summary [comma] brrrrrrrrrrrrrrrrrrrr.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Getting the CVS revision of Zsh

[Jun T.]

At 20:13 +0000 09.1.9, Peter Stephenson wrote:
> +patchlevel.h: $(sdir_top)/ChangeLog
> +	{ \
> +	  echo -n "#define ZSH_PATCHLEVEL "; \

This does not work on MacOSX 10.5 (Leopard), because sh's builtin
echo does not accept the option '-n':

Leopard$ /bin/sh -c 'echo -n foo'
-n foo
Leopard$ /bin/bash -c 'echo -n foo'
foo

A quick fix would be to use "/bin/echo -n" or "printf"
in place of "echo -n".

Re: Getting the CVS revision of Zsh

[Peter Stephenson]

On Tue, 13 Jan 2009 14:25:11 +0900
"Jun T." <takimoto-j@kba.biglobe.ne.jp> wrote:
> At 20:13 +0000 09.1.9, Peter Stephenson wrote:
> > +patchlevel.h: $(sdir_top)/ChangeLog
> > +	{ \
> > +	  echo -n "#define ZSH_PATCHLEVEL "; \
> 
> This does not work on MacOSX 10.5 (Leopard), because sh's builtin
> echo does not accept the option '-n':

OK, how about

Index: Src/zsh.mdd
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.mdd,v
retrieving revision 1.20
diff -u -r1.20 zsh.mdd
--- Src/zsh.mdd	9 Jan 2009 20:31:23 -0000	1.20
+++ Src/zsh.mdd	13 Jan 2009 10:08:06 -0000
@@ -42,11 +42,9 @@
 	echo '#define ZSH_VERSION "'$(VERSION)'"' > $@
 
 patchlevel.h: $(sdir_top)/ChangeLog
-	{ \
-	  echo -n "#define ZSH_PATCHLEVEL "; \
-	  sed -ne 's/^\* *\$$''Revision: \(.*\) ''\$$/"\1"/p' \
-	  $(sdir_top)/ChangeLog; \
-	} >patchlevel.h
+	sed -ne \
+	's/^\* *\$$''Revision: \(.*\) ''\$$/#define ZSH_PATCHLEVEL "\1"/p' \
+	$(sdir_top)/ChangeLog >patchlevel.h
 
 zshcurses.h: ../config.h
 	@if test x$(ZSH_CURSES_H) != x; then \



-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: Getting the CVS revision of Zsh

[Jun T.]

At 10:09 +0000 09.1.13, Peter Stephenson wrote:
>OK, how about

Thanks, it works.

Re: Getting the CVS revision of Zsh

[Peter Stephenson]

(I've moved this to zsh-workers, there doesn't seem to be anything left
of use to general users.)

Bart Schaefer wrote:
> If you're a packager like Debian or RedHat who occasionally ports
> individual patches backwards or sideways or makes your own stability
> patches, anything in these variables is going to be either wrong and
> misleading to the end user or fabricated and meaningless to the zsh
> developers upstream.

If that was what was going on, I would agree, but I did this on the
understanding that someone, for what ever reasons, might ship an
intermediate CVS checkout substantially unchanged as a development
package.  In fact, I thought this was basically what Debian did.
("Ship" might also mean "install for local users because they need a bug
fix or new feature before the release", or something of that kind.)
Then $ZSH_PATCHLEVEL tells you where it came from and what you can do
with it.  It gives the developers more information, too, if some
packaged is tracking CVS, without the package maintainers getting
involved.  It's worse than making a proper release, but better than not
having any idea about the provenance of the shell.

If someone is really bundling individual patches with zsh, so that it is
different from any CVS checkout, then I would urge them to alter
$ZSH_PATCHLEVEL to avoid exactly the sort of confusion you describe.  I
can add a config option to fix a patchlevel if this is useful.

> I was holding my tongue on ZSH_PATCHLEVEL despite my annoyance that
> it uses the RCS $Revision: tag -- I mirror the zsh sources into my
> own local repository, which means that tag gets rewritten whenever
> I do a check-in, so my local build will rarely if ever match the
> "real thing", hence it's useless cruft to me

Surely you can turn keyword expansion off on that file, if you want?
However, if you're never going to use it anyway then it *is* useless
cruft to you, of course.  By this definition a large part of the shell
is useless cruft to me, too.

Actually, I suspect I *will* use this myself occasionally.  It answers
those occasional development questions "did I install the version with
that bug fix, or did I just compile it, or am I dreaming again?"  No,
this is not a typical user case but for a few dozen bytes it's worth
it.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: Getting the CVS revision of Zsh

[Mikael Magnusson]

2009/1/14 Bart Schaefer <schaefer@brasslantern.com>:
> On Jan 14,  2:33pm, Richard Hartmann wrote:
> }
> } My suggestion would be to introduce a new variable called
> } $ZSH_RELEASE which is only filled if the source zsh was
> } compiled from is tagged as a release.
> }
> } Thoughts?
>
> My thought is that all of this, including ZSH_PATCHLEVEL, should
> never have been bothered with in the first place.
>
> Either you're compiling zsh from source yourself, in which case you
> should know what you're compiling; or you're using a package that was
> installed by somebody else, in which case it's between you and that
> somebody if you're having bleeding-edge non-releases forced on you.
>
> If you're a packager like Debian or RedHat who occasionally ports
> individual patches backwards or sideways or makes your own stability
> patches, anything in these variables is going to be either wrong and
> misleading to the end user or fabricated and meaningless to the zsh
> developers upstream.
>
> I was holding my tongue on ZSH_PATCHLEVEL despite my annoyance that
> it uses the RCS $Revision: tag -- I mirror the zsh sources into my
> own local repository, which means that tag gets rewritten whenever
> I do a check-in, so my local build will rarely if ever match the
> "real thing", hence it's useless cruft to me -- and I suppose it's
> up to PWS if he wants to jump through the hoops to make something
> like this appear to work, but I'm completely unconvinced by the
> argument that they're in some way beneficial.

FWIW, I use a git import which doesn't do any keyword expansion, so
the define is empty in my case, which obviously breaks the build. I
don't know if you want to a) not care b) add some #ifdef to set it to
"unknown" or such or c) add some shell code for git to set it.

If b or c I can construct a patch.

-- 
Mikael Magnusson

Re: Getting the CVS revision of Zsh

[Clint Adams]

On Wed, Jan 14, 2009 at 05:22:35PM +0000, Peter Stephenson wrote:
> If someone is really bundling individual patches with zsh, so that it is
> different from any CVS checkout, then I would urge them to alter
> $ZSH_PATCHLEVEL to avoid exactly the sort of confusion you describe.  I
> can add a config option to fix a patchlevel if this is useful.

Yes, we do this.  I can just patch zsh.mdd to work around it though.

Re: Getting the CVS revision of Zsh

[Peter Stephenson]

On Wed, 14 Jan 2009 23:36:59 +0000
Clint Adams <schizo@debian.org> wrote:
> On Wed, Jan 14, 2009 at 05:22:35PM +0000, Peter Stephenson wrote:
> > If someone is really bundling individual patches with zsh, so that it is
> > different from any CVS checkout, then I would urge them to alter
> > $ZSH_PATCHLEVEL to avoid exactly the sort of confusion you describe.  I
> > can add a config option to fix a patchlevel if this is useful.
> 
> Yes, we do this.  I can just patch zsh.mdd to work around it though.

In that case Bart's concerns are entirely real and this at least gives us
some kind of hook for people to indicate something funny is going on.

Arguably this should go after the standard version string in $ZSH_VERSION,
but I don't want yet more grief with additional customization.  I've spent
far too much time arguing about this already.

I'm fairly happy ZSH_PATCHLEVEL is enough at least for what I'd like it
do.  It's easy to find out what it should be in a released version and so
check if you're in a released version if you really need to.

Index: INSTALL
===================================================================
RCS file: /cvsroot/zsh/zsh/INSTALL,v
retrieving revision 1.37
diff -u -r1.37 INSTALL
--- INSTALL	30 Oct 2008 12:09:18 -0000	1.37
+++ INSTALL	15 Jan 2009 14:31:56 -0000
@@ -271,6 +271,19 @@
 CONFIGURATION OPTIONS
 =====================
 
+Modified versions of zsh
+------------------------
+
+If you are making local modifications to zsh, you are strongly
+advised to configure with the option
+
+  --enable-local-patchlevel="<my-mod-string>"
+
+so that the variable $ZSH_PATCHLEVEL indicates this is not a standard
+version of the shell.  The argument is arbitrary, but should indicate
+the entity that is customizing the shell, for example the OS vendor
+or distributor.
+
 Multibyte Character Support
 ---------------------------
 
Index: configure.ac
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.ac,v
retrieving revision 1.116
diff -u -r1.116 configure.ac
--- configure.ac	13 Jan 2009 17:10:22 -0000	1.116
+++ configure.ac	15 Jan 2009 14:31:56 -0000
@@ -304,6 +304,14 @@
 AC_SUBST(scriptdir)dnl
 AC_SUBST(sitescriptdir)dnl
 
+AH_TEMPLATE([CUSTOM_PATCHLEVEL],
+[Define to a custom value for the ZSH_PATCHLEVEL parameter])
+AC_ARG_ENABLE(custom-patchlevel,
+AC_HELP_STRING([--enable-custom-patchlevel], [set a custom ZSH_PATCHLEVEL value]),
+[if test x$enableval != x && test x$enableval != xno; then
+  AC_DEFINE_UNQUOTED([CUSTOM_PATCHLEVEL], ["$enableval"])
+fi])
+
 dnl Do you want maildir support?
 ifdef([maildir_support],[undefine([maildir_support])])dnl
 AH_TEMPLATE([MAILDIR_SUPPORT],
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.152
diff -u -r1.152 params.c
--- Src/params.c	9 Jan 2009 20:28:30 -0000	1.152
+++ Src/params.c	15 Jan 2009 14:31:57 -0000
@@ -31,7 +31,11 @@
 #include "params.pro"
 
 #include "version.h"
+#ifdef CUSTOM_PATCHLEVEL
+#define ZSH_PATCHLEVEL	CUSTOM_PATCHLEVEL
+#else
 #include "patchlevel.h"
+#endif
 
 /* what level of localness we are at */
  


-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: Getting the CVS revision of Zsh

[Peter Stephenson]

On Wed, 14 Jan 2009 19:54:02 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> FWIW, I use a git import which doesn't do any keyword expansion, so
> the define is empty in my case, which obviously breaks the build. I
> don't know if you want to a) not care b) add some #ifdef to set it to
> "unknown" or such or c) add some shell code for git to set it.
> 
> If b or c I can construct a patch.

If keyword expansion is properly turned off it shouldn't remove the CVS
one, although I don't know the details of how git works.  The second
option is probably the easiest; it's straightforward now sed outputs the
entire line, so the definition is completely missing if not found.

Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.153
diff -u -r1.153 params.c
--- Src/params.c	15 Jan 2009 14:49:51 -0000	1.153
+++ Src/params.c	15 Jan 2009 19:42:36 -0000
@@ -35,6 +35,11 @@
 #define ZSH_PATCHLEVEL	CUSTOM_PATCHLEVEL
 #else
 #include "patchlevel.h"
+
+/* If removed from the ChangeLog for some reason */
+#ifndef ZSH_PATCHLEVEL
+#define ZSH_PATCHLEVEL "unknown"
+#endif
 #endif
 
 /* what level of localness we are at */

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/