Skip site navigation (1) Skip section navigation (2)

Re: port _srv.o makefile rules don't observe dependency tracking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: port _srv.o makefile rules don't observe dependency tracking
Date: 2012-05-01 20:43:23
Message-ID: 20522.1335905003@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of mar may 01 16:25:07 -0400 2012:
>> Are there, or might there be in the future, any "port" files that only
>> exist in server flavor and not client-side flavor?

> Now, there is someone with a patch that duplicates some libpq code into
> psql (pqSocketPoll I think it is) and I was considering suggesting that
> instead of exporting the libpq function, the implementation could be put
> in a src/port/ file instead, so that psql can also use it.  I'm not sure
> if that's really a good idea but if so it would be a first file to be
> only in -DFRONTEND form.

Offhand it seems to me that anything that can be built with -DFRONTEND
should be buildable without, so the worst possible consequence here is
having an unused member of libpgport_srv.a.  I was worried about the
other way around, where we have something that (say) depends on elog
or palloc and so can't be built at all in frontend form.  I guess you
could argue that any such code ought not be in src/port/ in the first
place.

Anyway, I'm not objecting to the patch, just raising something to
consider.  If it doesn't bother anybody, let's go with this.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2012-05-01 20:45:51
Subject: Re: port _srv.o makefile rules don't observe dependency tracking
Previous:From: Robert HaasDate: 2012-05-01 20:39:42
Subject: Re: extending relations more efficiently

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group