Re: make clean didn't clean up files generated from *.(y|l)
От | Tom Lane |
---|---|
Тема | Re: make clean didn't clean up files generated from *.(y|l) |
Дата | |
Msg-id | 22727.1467176247@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | make clean didn't clean up files generated from *.(y|l) (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Ответы |
Re: make clean didn't clean up files generated from
*.(y|l)
|
Список | pgsql-hackers |
Kouhei Kaigai <kaigai@ak.jp.nec.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
В списке pgsql-hackers по дате отправления: