zsh-workers
 help / color / mirror / code / Atom feed
From: Wesley <opndev@protonmail.com>
To: zsh-workers@zsh.org
Subject: Re: [PATCH] Show patchlevel in version string
Date: Wed, 09 Aug 2023 13:05:01 +0000	[thread overview]
Message-ID: <29b20e30-ab14-3f7e-494f-6702aa4a6d01@protonmail.com> (raw)
In-Reply-To: <20220410213529.GD27526@tarpaulin.shahaf.local2>



On 4/10/22 17:35, Daniel Shahaf wrote:
> Wesley Schwengle wrote on Fri, Sep 03, 2021 at 13:38:03 -0400:
>> After this patch is applied, you get to see the following version string
>> after you configured zsh with `--enable-custom-patchlevel=$(git describe)':
>>
>>    $ ./Src/zsh --version
>>    zsh 5.8.0.2-dev (x86_64-pc-linux-gnu/zsh-5.8-481-g64befeb4c)
>
> Adding the git revision there makes sense, I suppose, but why should
> this only be done when that configure option is used?  The git revision
> is added to ZSH_PATCHLEVEL (which is a shell variable, not an
> environment variable) by default, without needing any configure flags.
>
> Or another perspective: CUSTOM_PATCHLEVEL is used to cause
> $ZSH_PATCHLEVEL to be set to something other than its default.  So,
> why shouldn't the #else branch emit the default value of $ZSH_PATCHLEVEL?
>
> tl;dr: Why not include the (build's default) value of $ZSH_PATCHLEVEL in
> the output?

I missed this thread, I thought it went dead after my original
submission. I didn't get the memo ;) Sorry for the delay on my part.

To answer the question: Why not for all builds? I don't think regular
release builds would include this. I borrowed the approach from git,
although they do what you are asking. Git uses GIT-VERSION-GEN[^1] in
their Makefile[^2] to include the options in their build process. I'm
not all the confident with Makefile voodoo. I just thought it was handy
for those who want it and my thought was that most developers have some
kind of custom install zsh where they can add this logic.

If you want it for every build, I would need to get some help from
someone who is sufficient at Makefiles probably. I can look into it
regardless. But my question is than, would the same approach as git
takes be ok with you?

[^1]: https://github.com/git/git/blob/master/GIT-VERSION-GEN
[^2]: https://github.com/git/git/blob/master/Makefile

--
Wesley Schwengle




  reply	other threads:[~2023-08-09 13:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 17:38 Wesley Schwengle
2022-03-31  5:43 ` Lawrence Velázquez
2022-03-31  7:55 ` Axel Beckert
2023-08-13 18:25   ` Wesley Schwengle
2022-04-10 21:35 ` Daniel Shahaf
2023-08-09 13:05   ` Wesley [this message]
2023-08-13 18:54   ` Wesley Schwengle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29b20e30-ab14-3f7e-494f-6702aa4a6d01@protonmail.com \
    --to=opndev@protonmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).