Re: Getting the CVS revision of Zsh

[Mikael Magnusson <mikachu@xxxxxxxxx>]

2009/1/14 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>:
> 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