From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: make clean didn't clean up files generated from *.(y|l) |
Date: | 2016-06-29 04:57:27 |
Message-ID: | 22727.1467176247@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
> I tried to build the latest master branch just after the switch from
> REL9_5_STABLE and "make clean", however, repl_gram.c was not cleaned
> up correctly. So, my problem is that repl_gram.l was the latest version,
> but compiler saw the repl_gram.c generated based on the v9.5 source.
> ...
> Probably, we have to add explicit cleanup of these auto-generated files
> on Makefiles.
"make clean" absolutely should NOT remove that file; not even "make
distclean" should, because we ship it in tarballs. Likewise for the other
bison product files you mention, as well as a boatload of other derived
files.
If you want to checkout a different release branch in the same working
directory, I'd suggest "make maintainer-clean" or "git clean -dfx" first.
(Personally I don't ever do that --- it's much easier to maintain a
separate workdir per branch.)
Having said that, switching to a different branch should have resulted in
repl_gram.l being updated by git, and thereby acquiring a new file mod
date; so I don't understand why make wouldn't have chosen to rebuild
repl_gram.c. Can you provide a reproducible sequence that makes this
happen?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2016-06-29 05:38:43 | Re: Postgres_fdw join pushdown - wrong results with whole-row reference |
Previous Message | Amit Kapila | 2016-06-29 04:29:48 | Re: Rename max_parallel_degree? |