On 12/29/24 08:29, Bruno Haible wrote:
Re 1 + max: yes that makes sense, also for compensating a conversion
to entire seconds, that loses fractional seconds.
In TZDB releases all the files either correspond to a commit and
therefore lack fractional seconds (because Git doesn't record frac
Hi Paul,
> >timestamp(Y) := max (vmtime(X1), vmtime(X2), ..., vmtime(Xn)).
> >
> > where vmtime(X) is defined as:
> >
> > - if X is under version control and not modified locally:
> > $(git log -1 --format=%ct X),
> > that is, the last time file X was modified under version c
On 12/28/24 12:07, Simon Josefsson wrote:
I tried on cfarm's AIX 7.1 and 7.3 with /usr/bin/make and
libidn and it worked fine.
Oh, I thought AIX had the problem because it exhibits this behavior:
$ echo 't: s; cp -p s t' >Makefile
$ touch s
$ make
cp -p s t
$ make
c
Paul Eggert writes:
> On 12/28/24 10:08, Simon Josefsson wrote:
>>> some 'make's treat
>>> equal timestamps as meaning the destination is out of date and needs
>>> to be rebuilt. (Although POSIX does not require this 'make' behavior,
>>> it encourages it.)
>> Which 'make' behave like that?
>
> AI
On 12/28/24 10:08, Simon Josefsson wrote:
some 'make's treat
equal timestamps as meaning the destination is out of date and needs
to be rebuilt. (Although POSIX does not require this 'make' behavior,
it encourages it.)
Which 'make' behave like that?
AIX and HP-UX 'make', to my knowledge. I wou
On 12/26/24 17:06, Bruno Haible via Gnulib discussion list wrote:
Rather than assign a silly
EPOCH_DATE or some other nonsense [1], the idea would be to take
timestamp(Y) := max (vmtime(X1), vmtime(X2), ..., vmtime(Xn)).
where vmtime(X) is defined as:
- if X is under version control and
Paul Eggert writes:
> On 12/28/24 04:38, Simon Josefsson via Gnulib discussion list wrote:
>> The tarball use the same
>> mtime for all files.
>> So I don't understand this concern. What problem do you see if you
>> don't perform those steps?
>
> I must be missing something because for many tarb
On 12/28/24 04:38, Simon Josefsson via Gnulib discussion list wrote:
The tarball use the same
mtime for all files.
So I don't understand this concern. What problem do you see if you
don't perform those steps?
I must be missing something because for many tarballs it's obvious that
one shouldn
Bruno Haible via Gnulib discussion list writes:
> Simon Josefsson wrote:
>> Oh, that is neat! But is there any advantage compared to simply using a
>> global mtime for all files in the tarball?
>
> For the specific case of creating a tarball, I see three advantages:
>
> * When you pick a globa
Simon Josefsson wrote:
> Oh, that is neat! But is there any advantage compared to simply using a
> global mtime for all files in the tarball?
For the specific case of creating a tarball, I see three advantages:
* When you pick a global mtime for all files, you need to pick it in a
way that
Bruno Haible writes:
> Simon Josefsson wrote:
>> I'm not sure I follow what you actually plan to do wrt multiple files
>> X1, X2, ... Xn. Can you give some code example? Maybe I understand
>> that better...
>
> Roughly like this (untested).
Oh, that is neat! But is there any advantage compare
Simon Josefsson wrote:
> I'm not sure I follow what you actually plan to do wrt multiple files
> X1, X2, ... Xn. Can you give some code example? Maybe I understand
> that better...
Roughly like this (untested).
# func_file_vmtime returns the virtual modification time of a file,
# as a number of
Bruno Haible via Gnulib discussion list writes:
> Simon Josefsson wrote on 2024-12-12:
>> +TAR_OPTIONS += --mode=go+u,go-w --mtime=$(abs_top_srcdir)/NEWS
>>
>> and to Makefile.am:
>>
>> +dist-hook: mtime-NEWS-to-git-HEAD
>> +.PHONY: mtime-NEWS-to-git-HEAD
>> +mtime-NEWS-to-git-HEAD:
>> +$(A
Simon Josefsson wrote on 2024-12-12:
> +TAR_OPTIONS += --mode=go+u,go-w --mtime=$(abs_top_srcdir)/NEWS
>
> and to Makefile.am:
>
> +dist-hook: mtime-NEWS-to-git-HEAD
> +.PHONY: mtime-NEWS-to-git-HEAD
> +mtime-NEWS-to-git-HEAD:
> + $(AM_V_GEN)if test -e $(srcdir)/.git \
> +
14 matches
Mail list logo
