Re: [RFC] building postgres with meson - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [RFC] building postgres with meson
Date
Msg-id 77dd41cf-05a6-06c9-b2da-62d3a1036118@dunslane.net
Whole thread Raw
In response to Re: [RFC] building postgres with meson  (Andres Freund <andres@anarazel.de>)
Responses Re: [RFC] building postgres with meson
List pgsql-hackers
On 2022-08-09 Tu 03:10, Andres Freund wrote:
> Hi,
>
> I was looking at re-unifying gendef2.pl that the meson patchset had introduced
> for temporary ease during hacking with gendef.pl. Testing that I noticed that
> either I and my machine is very confused, or gendef.pl's check whether it can
> skip work is bogus.
>
> I noticed that, despite having code to avoid rerunning when the input files
> are older than the .def file, it always runs.
>
> # if the def file exists and is newer than all input object files, skip
> # its creation
> if (-f $deffile
>     && (-M $deffile > max(map { -M } <$ARGV[0]/*.obj>)))
> {
>     print "Not re-generating $defname.DEF, file already exists.\n";
>     exit(0);
> }
>
> My understanding of -M is that it returns the time delta between the file
> modification and the start of the script. Which makes the use of max() bogus,
> since it'll return the oldest time any input has been modified, not the
> newest. And the condition needs to be inverted, because we want to skip the
> work if $deffile is *newer*, right?
>
> Am I missing something here?


No, you're right, this is bogus. Reversing the test and using min
instead of max is the obvious fix.


> I'm tempted to just remove the not-regenerating logic - gendef.pl shouldn't
> run if there's nothing to do, and it'll e.g. not notice if there's an
> additional input that wasn't there during the last invocation of gendef.pl.
>

Maybe, need to think about that more.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Generalize ereport_startup_progress infrastructure
Next
From: David Rowley
Date:
Subject: Re: Reducing the chunk header sizes on all memory context types