Re: [COMMITTERS] pgsql: Link postgres from all object files at once, to avoid the

Log Message:
-----------
Link postgres from all object files at once, to avoid the error-prone
SUBSYS.o step and allow for better optimization by the linker.

Instead of partial linking into SUBSYS.o, the list of object files is
assembled in objfiles.txt files that are expanded when the final
linking is done.

Because we are not yet sure how long command lines different platforms
can handle, the old way of linking is still available, by defining the
make variable PARTIAL_LINKING (e.g., make all PARTIAL_LINKING=1). If
we determine that this is necessary for some platforms, then we will
document this in a more prominent place.

Modified Files:
--------------
pgsql/src/backend:
Makefile (r1.125 -> r1.126)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/Makefile?r1=1.125&r2=1.126)
common.mk (r1.1 -> r1.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/common.mk?r1=1.1&r2=1.2)

petere(at)postgresql(dot)org (Peter Eisentraut) writes:
> Instead of partial linking into SUBSYS.o, the list of object files is
> assembled in objfiles.txt files that are expanded when the final
> linking is done.

BTW, why does this patch force objfiles.txt to be regenerated every time
any individual .o file is rebuilt? Surely it need only depend on the
specific Makefile (and maybe Makefile.global).

I find the current behavior kind of annoying because the echo command
occupies more than a full window in some subdirectories (eg utils/adt),
making it necessary to scroll back to see whether one's recompile of a
couple of modified files generated any warnings. If the dependencies
need to stay as they are, maybe we could avoid the annoyance by having
make not print the echo command.

regards, tom lane

Hm, just noticed another little annoyance: CVS is going to complain about
the objfiles.txt files unless we add a .cvsignore entry to every last
subdirectory of the backend. That seems like a lot of maintenance
tedium. I wonder if there's another way, such as using a file name that
CVS is already programmed to ignore.

regards, tom lane

On Mon, 25 Feb 2008 21:39:27 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hm, just noticed another little annoyance: CVS is going to complain about
> the objfiles.txt files unless we add a .cvsignore entry to every last
> subdirectory of the backend. That seems like a lot of maintenance
> tedium. I wonder if there's another way, such as using a file name that
> CVS is already programmed to ignore.

Why not just add it to CVSROOT/cvsignore?

--
D'Arcy J.M. Cain <darcy(at)druid(dot)net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

"D'Arcy J.M. Cain" <darcy(at)druid(dot)net> writes:
> On Mon, 25 Feb 2008 21:39:27 -0500
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hm, just noticed another little annoyance: CVS is going to complain about
>> the objfiles.txt files unless we add a .cvsignore entry to every last
>> subdirectory of the backend. That seems like a lot of maintenance
>> tedium. I wonder if there's another way, such as using a file name that
>> CVS is already programmed to ignore.

> Why not just add it to CVSROOT/cvsignore?

Shows you how little I know about CVS repository administration ;-)
Yeah, that sounds like a simple fix.

regards, tom lane

Tom Lane wrote:
> Hm, just noticed another little annoyance: CVS is going to complain about
> the objfiles.txt files unless we add a .cvsignore entry to every last
> subdirectory of the backend.

Complain how? Why should it complain more or less than about the SUBSYS.o
files?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> Hm, just noticed another little annoyance: CVS is going to complain about
>> the objfiles.txt files unless we add a .cvsignore entry to every last
>> subdirectory of the backend.

> Complain how?

Try a "cvs diff" or "cvs update" while these files are present.

> Why should it complain more or less than about the SUBSYS.o
> files?

It has a hard-wired rule not to complain about files named *.o.

regards, tom lane

Am Dienstag, 26. Februar 2008 schrieb Tom Lane:
> > Why should it complain more or less than about the SUBSYS.o
> > files?
>
> It has a hard-wired rule not to complain about files named *.o.

Well, we could name the output file SUBSYS.o if that is not too confusing. :)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Dienstag, 26. Februar 2008 schrieb Tom Lane:
>>> Why should it complain more or less than about the SUBSYS.o
>>> files?
>>
>> It has a hard-wired rule not to complain about files named *.o.

> Well, we could name the output file SUBSYS.o if that is not too confusing. :)

Yeah, it probably is. D'Arcy's suggestion of modifying our
CVSROOT/cvsignore file seems better.

regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>
>> Am Dienstag, 26. Februar 2008 schrieb Tom Lane:
>>
>>>> Why should it complain more or less than about the SUBSYS.o
>>>> files?
>>>>
>>> It has a hard-wired rule not to complain about files named *.o.
>>>
>
>
>> Well, we could name the output file SUBSYS.o if that is not too confusing. :)
>>
>
> Yeah, it probably is. D'Arcy's suggestion of modifying our
> CVSROOT/cvsignore file seems better.
>
>

+1. Calling it something like foo.o when it isn't an object file would
be horrible. This should be a simple one-off operation.

cheers

andrew