Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Jan 22, 2014, 16:42 UTC
- Message-ID
- <52DFF4E8.8060605@viscovery.net>
- In-Reply-To
- <xmqq38kgyozt.fsf@gitster.dls.corp.google.com>
Am 1/22/2014 17:12, schrieb Junio C Hamano:
Show 24 quoted lines
> Johannes Sixt <j.sixt@viscovery.net> writes: > >> [Cc Pat, who added git.rc] >> >> Am 1/22/2014 0:48, schrieb Junio C Hamano: >>> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes: >>> >>>>> Note that I am merely guessing that "short-digit" version numbers >>>>> are acceptable by now after seeing >>>>> >>>>> https://sourceware.org/ml/binutils/2012-07/msg00199.html >>>> >>>> Ah, nice find! >>>> >>>> I will test your patch (below) and let you know soon, but it looks >>>> good to me. (I can't test it tonight, unfortunately.) >>> >>> One thing to note is that I don't know why the existing code dropped >>> the fourth digit from the maintenance series. >> >> I don't know either. But it does not really matter. When there are 4 >> digits in the FILEVERSION and PRODUCTVERSION statements, then the user >> does not see them as-are, but, for example, 1.8.1283 for >> FILEVERSION 1,8,5,3 (1283 = 5*256+3). Therefore, I think that there is
I just noticed that I'm wrong here: The user will see "1.8.5.3". But I think it makes no difference. Read on.
Show 5 quoted lines
>> no point in providing 4 numbers, and the patch below should be >> sufficient. > > Would that work well when we do 1.9.1, the first maintenance/bugfix > release for 1.9?
Define "work well".
The numbers defined in {FILE,PRODUCT}VERSION statements are intended for machine consumption and are always 4 positions (if the source contains fewer, they are padded with zeros). They can be used by installers to decide whether a file that already exists in the system should be overwritten by a newer version.
Unfortunately, these numbers are visible when the user invokes Properties from the context menu of git.exe in the file manager and then switches to the "Version" tab. All 4 positions are always listed. Therefore, the user will see "1.9.0.0" for the first release of the 1.9 series, which is "wrong", because you will call "1.9", not "1.9.0.0", I assume.
With sufficient effort, we could achieve that version 1.9.1 is listed as "1.9.1.0". That is still "wrong".
Since we can't get this display right, I suggest that we just punt (as per my patch). That should work out nicely because we can fairly safely assume that there are no installers around that look at these particular version numbers.
BTW, that same "Version" tab will have another entry, called "Product Version" later in the list. This one lists the string that we pass in -DGIT_VERSION (see quoted context below). It is the truely correct version that *users* should be interested in.
Show 27 quoted lines
> >> diff --git a/Makefile b/Makefile >> index b4af1e2..99b2b89 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -1773,7 +1773,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES >> >> git.res: git.rc GIT-VERSION-FILE >> $(QUIET_RC)$(RC) \ >> - $(join -DMAJOR= -DMINOR= -DPATCH=, $(wordlist 1,3,$(subst -, ,$(subst ., ,$(GIT_VERSION))))) \ >> + $(join -DMAJOR= -DMINOR=, $(wordlist 1,2,$(subst -, ,$(subst ., ,$(GIT_VERSION))))) \ >> -DGIT_VERSION="\\\"$(GIT_VERSION)\\\"" $< -o $@ >> >> ifndef NO_PERL >> diff --git a/git.rc b/git.rc >> index bce6db9..33aafb7 100644 >> --- a/git.rc >> +++ b/git.rc >> @@ -1,6 +1,6 @@ >> 1 VERSIONINFO >> -FILEVERSION MAJOR,MINOR,PATCH,0 >> -PRODUCTVERSION MAJOR,MINOR,PATCH,0 >> +FILEVERSION MAJOR,MINOR,0,0 >> +PRODUCTVERSION MAJOR,MINOR,0,0 >> BEGIN >> BLOCK "StringFileInfo" >> BEGIN