Message-ID: <77dd41cf-05a6-06c9-b2da-62d3a1036118@dunslane.net>
Date: Tue, 9 Aug 2022 08:37:16 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [RFC] building postgres with meson
Content-Language: en-US
To: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org,
 Magnus Hagander <magnus@hagander.net>
References: <20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de>
 <20220809071055.rgikv3qn74ypnnbb@awork3.anarazel.de>
From: Andrew Dunstan <andrew@dunslane.net>
In-Reply-To: <20220809071055.rgikv3qn74ypnnbb@awork3.anarazel.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/77dd41cf-05a6-06c9-b2da-62d3a1036118%40dunslane.net>
Precedence: bulk


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