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: (view raw, whole thread or download thread mbox)
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

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-2018 The PostgreSQL Global Development Group