Re: meson PGXS compatibility - Mailing list pgsql-hackers

Hi,

On 2022-10-05 16:20:22 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> >   On macOS we ran ranlib after installing a static library. This was added a
> >   long time ago, in 58ad65ec2def. I cannot reproduce an issue in more recent
> >   macOS versions.
> 
> I agree that shouldn't be necessary anymore (and if it is, we'll find
> out soon enough).

Cool.


> >   I'm on the fence about removing the "touch $@" from the rule building static
> >   libs. That was added because of macos's ranlib not setting fine-grained
> >   timestamps. On a modern mac ar and ranlib are the same binary, and maybe
> >   that means that ar has the same issue? Both do set fine-grained
> >   timestamps:
> 
> Please see the commit message for 826eff57c4c: the issue seems to arise
> only with specific combinations of software, in particular with non-Apple
> versions of "make" (although maybe later Apple builds have fixed make's
> failure to read sub-second timestamps?).

My understanding, from that commit message, was that the issue originates 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?


> That's a relatively recent hack, and I'm very hesitant to conclude that we
> don't need it anymore just because you failed to reproduce an issue locally.

Yea, that's why I was hesitant as well. I'll reformulate the comment to
reference ar instead of ranlib instead.


> It very possibly isn't a problem in a meson build, though, depending on how
> much meson depends on file timestamps.

Most of the timestamp sensitive stuff is dealt with by ninja, rather than
meson. ninja does take timestamps into account when determining what to
rebuild - although I suspect this specific problem wouldn't occur even with a
problematic ar/ranlib version, because the relevant timestamps will be on the
.c (etc) files, rather than the .a. Ninja has the whole dependency graph, so
it knows what dependencies it has to rebuild, without needing to check
timestamps of intermediary objects.

Ninja does support build rules where it checks the timestamps of build outputs
to see if targets depending on those build outputs have to be rebuilt, or not,
because the target didn't change. But the relevant option ("restat") isn't set
for compiler / linker invocations in the build.ninja meson generates.

Restat is however set for the "custom_command"s we use to generate all kinds
of sources. Sometimes that leads to the set of build steps shrinking
rapidly. E.g. a touch src/include/catalog/pg_namespace.dat starts leads to
ninja considering 1135 targets out of date, but as genbki.pl doesn't end up
changing any files, it's done immediately after that...

[1/1135 1   0%] Generating src/include/catalog/generated_catalog_headers with a custom command

Greetings,

Andres Freund