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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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