Feedback-ID: id4a34324:Fastmail
Date: Tue, 9 Aug 2022 00:10:55 -0700
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>,
	Magnus Hagander <magnus@hagander.net>
Subject: Re: [RFC] building postgres with meson
Message-ID: <20220809071055.rgikv3qn74ypnnbb@awork3.anarazel.de>
References: <20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de>
Archived-At: 
 <https://www.postgresql.org/message-id/20220809071055.rgikv3qn74ypnnbb%40awork3.anarazel.de>
Precedence: bulk

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?


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.

Greetings,

Andres Freund