Re: Shipping documentation untarred
От
Tom Lane
Тема
Re: Shipping documentation untarred
Дата
Msg-id
8537.1249999321@sss.pgh.pa.us
Ответ на
Re: Shipping documentation untarred (Peter Eisentraut)
Список
Дерево обсуждения
Shipping documentation untarred Peter Eisentraut <peter_e@gmx.net>
Re: Shipping documentation untarred Bruce Momjian <bruce@momjian.us>
Re: Shipping documentation untarred Peter Eisentraut <peter_e@gmx.net>
Re: Shipping documentation untarred Alvaro Herrera <alvherre@commandprompt.com>
Re: Shipping documentation untarred Peter Eisentraut <peter_e@gmx.net>
Re: Shipping documentation untarred Peter Eisentraut <peter_e@gmx.net>
Re: Shipping documentation untarred Tom Lane <tgl@sss.pgh.pa.us>
Re: Shipping documentation untarred Peter Eisentraut <peter_e@gmx.net>
Re: Shipping documentation untarred Magnus Hagander <magnus@hagander.net>
Re: Shipping documentation untarred Peter Eisentraut <peter_e@gmx.net>
Peter Eisentraut writes: > I've been thinking that we could actually get rid of that build-in-srcdir > behavior, which also occasionally puzzles vpath users with respect to gram.c > and so on. The new behavior would be to build targets in the local directory. > The only requirement would be that distribution tarballs be built in-tree, so > that the stuff that is distprep'ed actually ends up in the tarball, but I > think that should not be a problem. I think one of the arguments for the current behavior is that the derived files are platform-independent, so this way saves work if you are building several sets of binaries from the same source tree. However, I don't know of anyone actively making use of that behavior --- and if they did want to, they'd likely use a tarball not a CVS pull anyway. Having all the derived files in the build directory definitely seems to me to reduce the complexity and surprise factor, so +1 for changing. regards, tom lane
В списке pgsql-hackers по дате отправления
От: Magnus Hagander
Дата: