From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@postgresql.org, Nazir Bilal Yavuz <byavuz81@gmail.com>,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: meson PGXS compatibility
In-reply-to: <20221005204944.cwkaod6hfok2w7vj@awork3.anarazel.de>
References: <20221005200710.luvw5evhwf6clig6@awork3.anarazel.de>
 <2551486.1665001222@sss.pgh.pa.us>
 <20221005204944.cwkaod6hfok2w7vj@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Wed, 05 Oct 2022 13:49:44 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2555940.1665003526.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 05 Oct 2022 16:58:46 -0400
Message-ID: <2555941.1665003526@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2555941.1665003526%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> My understanding, from that commit message, was that the issue originate=
s in
> apple's ranlib setting the timestamp to its components but only queries =
/ sets
> it using second granularity. I verified that apple's ranlib and ar these=
 days
> just set the current time, at a high granularity, as the mtime.  Whether=
 or
> not make then hides the problem seems not that relevant if the source of=
 the
> problem is gone, no?

Well, (a) it seemed to happen in only some circumstances even back then,
so maybe your testing didn't catch it; and (b) even assuming that Apple
has fixed it in recent releases, there may still be people using older,
un-fixed versions.  Why's it such a problem to keep the "touch" step?

			regards, tom lane