Inconsitency between configure build and Windows build after commit 9d0f14(was Re: commit 9d0f14)

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Tatsuro MATSUOKA <tma...@ya...>
> To: Mojca Miklavec <moj...@gm...>; Ethan Merritt <eam...@gm...>
> Cc: gnu...@li...; Merritt Ethan <sf...@us...>
> Date: 2018/3/23, Fri 16:43
> Subject: Re: commit 9d0f14
> 
> ----- Original Message -----
> 
>>  From: Mojca Miklavec 
>>  To: Ethan Merritt 
>>  Cc: gnuplot-beta ; Ethan A Merritt
>>  Date: 2018/3/23, Fri 05:16
>>  Subject: Re: commit 9d0f14
>> 
>>  On 22 March 2018 at 19:26, Ethan Merritt wrote:
>>> 
>>>   Here's a different idea.
>>>   Does git gurantee to preserve the modification date attribute of files 
> in
>>>   the repository?
>> 
>>  I'm not sure what you are asking exactly, but:
>> 
>>  - Git doesn't remember original modification time of any file. That
>>  is: you cannot take a file that was last modified on March 1st, commit
>>  it today, clone repository and get that info about the 1st of March in
>>  any way. The original modification timestamp is lost.
>>  - What git *does* remember is commit timestamp, or rather two
>>  timestamps, timestamp of when the author committed this first and then
>>  another timestamp in case of further
>>  modifications/merging/rebasing/cherry-picking etc. (git calls that
>>  "author" and "committer" timestamp; you can manually 
> specify 
>>  those
>>  timestamps of course, but that's a different issue)
>> 
>>  When you switch back and forth between branches, the last modification
>>  time of files on the disk will change, I think.
>> 
>>  There is a way to enforce a consistent timing with a built-in function
>>  to generate tarbals for example, but I don't think you can rely on
>>  that feature unless you take some special care. By default all the
>>  files you check out will have the timestamp of the time when you
>>  cloned repository or pulled in new changes or switched between
>>  branches rather than the timestamp of the actual change in repository.
>> 
>>>   I observe that it does this in practice, but maybe it is not a 
> guarantee.
>>>   We don't really need to alter the _contents_ of a timestamp file,  
> just 
>>  its
>>>   modification date.
>> 
>>  See above, I don't believe this would in practice be any less random
>>  than the build timestamp. Ok, at least it will be reproducible on the
>>  same machine, so slightly less randomness :)
>> 
>>  Here are some ideas:
>>    
>> 
> https://stackoverflow.com/questions/1704907/how-can-i-get-my-c-code-to-automatically-print-out-its-git-version-hash
>> 
>>  If the only problem of "git describe" is support for 
> out-of-source
>>  builds, couldn't the Makefile simply do something like
>> 
>>      # remember current build-dir
>>      cd source-dir
>>      version=`git describe ...`
>>      cd build-dir
>>      echo $version > versionfile.txt
>> 
>>  (consider this to be pseudo-code). If git fails in this case, then go
>>  for version written elsewhere of course.
>> 
>>  Mojca
>> 
> 
> 
> In my opinion, for development version of open source software, 
> git or mercurial version hash is essential.
> 
> I vote to the Mojca's proposal.
> 
> Tatsuro
> 

On Unixy platform, mechanism of timestamp.h is changed.
However, windows Makefile is not changed accordingly.

I personally do not like the change of commit 9d0f14.
However, inconsistency is not also good thing.

Tatsuro