Re: Shipping documentation untarred

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Shipping documentation untarred
Дата
Msg-id
8537.1249999321@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
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 по дате отправления
От: Dimitri Fontaine
Дата:
От: Magnus Hagander
Дата:
FAQ