From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: [RFC] building postgres with meson |
Date: | 2022-08-09 12:37:16 |
Message-ID: | 77dd41cf-05a6-06c9-b2da-62d3a1036118@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-08-09 12:53:04 | Re: Reducing the chunk header sizes on all memory context types |
Previous Message | Robert Haas | 2022-08-09 12:35:24 | Re: Generalize ereport_startup_progress infrastructure |