From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Preserve intermediate .c files in coverage mode |
Date: | 2012-10-30 21:28:03 |
Message-ID: | 21072.1351632483@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Sun, 2012-10-28 at 11:10 -0400, Tom Lane wrote:
>> [ blink... ] I'd vote for making them precious all the time. No such
>> behavioral change was discussed or agreed to,
> This is standard, default make behavior. It only showed up here because
> the coverage processing doesn't list all the files it needs in make
> rules.
Yeah, I know it's "default", but it's not how our make files ever
treated these files before. At the risk of repeating myself: a change
of this sort was not discussed nor agreed to. And I'm not agreeing to
it. I don't care for the idea that the build tree after a regular make
might not include all files that would be in a distribution tarball.
A concrete usage case that this breaks is doing something like
find . -name '*.c' | xargs grep whatever
Up to now I've always been able to assume that that would catch
occurrences of "whatever" coming from *.y and *.l files. No more
though. Maybe the derived *.c files are there, or maybe they're
not --- it'll be really history-dependent.
Please just make them precious.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-10-31 13:54:47 | pgsql: Fix ALTER EXTENSION / SET SCHEMA |
Previous Message | Peter Eisentraut | 2012-10-30 21:11:14 | Re: [COMMITTERS] pgsql: Preserve intermediate .c files in coverage mode |
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2012-10-30 21:47:34 | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
Previous Message | Josh Berkus | 2012-10-30 21:25:23 | Re: Proposal for Allow postgresql.conf values to be changed via SQL |