Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
Date: 2010-01-05 03:53:07
Message-ID: 407d949e1001041953n29596b6kcf41f753cc078e6b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Tue, Jan 5, 2010 at 3:42 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane <tgl(at)postgresql(dot)org> wrote:
>> Log Message:
>> -----------
>> Remove too-smart-for-its-own-good optimization of not overwriting the output
>> files when they haven't changed.  This confuses make because the build fails
>> to update the file timestamps, and so it keeps on doing the action over again.
>
> This doesn't seem like a good idea.  Not rebuilding the output files
> also saves recompiling the things that depend on them.  For the BKI
> files thast doesn't matter much, but for schemapg.h it might be
> significant.  Certainly, if we move to generating more header files
> this way, it WILL be significant.  If running the script is cheap (and
> it should be), it's better to take that hit rather than recompiling a
> whole mess of .c files unnecessarily.


I think there's a trick to cover this case but I don't recall what it is.

Does generating a stamp file help? If you had a rule saying to trigger
generating the output files because the stamp file is out of date
which might or might not touch the .h file which would trigger more
files to be rebuilt then everything should work.... except I fear this
leads us back to the "make rule which generates two files" problem...

-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-01-05 03:54:20
Subject: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
Previous:From: Tom LaneDate: 2010-01-05 03:51:34
Subject: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting

pgsql-committers by date

Next:From: Robert HaasDate: 2010-01-05 03:54:20
Subject: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
Previous:From: Tom LaneDate: 2010-01-05 03:51:34
Subject: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group