> Kouhei Kaigai <kai...@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? > Ah, I might have inadequate operation just before the branch switching.
$ cd ~/source/pgsql <-- REL9_5_STABLE; already built $ git checkout master $ cp -r ~/source/pgsql ~/repo/pgsql-kg $ cd ~/repo/pgsql-kg $ ./configure $ make clean $ make <-- repl_gram.c raised an error ~/source/pgsql is a copy of community's branch; with no my own modification. To keep it clean, I copied entire repository to other directory, but cp command updated the file modification timestamp. I may be the reason why repl_gram.c was not rebuilt. Sorry for the noise. -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
