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

Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:

Instead, I thought this could easily be fixed by writing this:

%_srv.o: %.c %.o
$(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $< -o $@

A bit hacky, but should get quite robust results.

So basically to build the _srv.o file you first need to build the .o?
Since both files need to be built anyway, I don't think this is a
problem.

There's the slight disadvantage that if you say "make -j" you only get
21 concurrent gcc processes instead of 40-some, but I doubt this is a
problem in practice, either.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:

Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:

Instead, I thought this could easily be fixed by writing this:

%_srv.o: %.c %.o
$(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $< -o $@

A bit hacky, but should get quite robust results.

So basically to build the _srv.o file you first need to build the .o?
Since both files need to be built anyway, I don't think this is a
problem.

Are there, or might there be in the future, any "port" files that only
exist in server flavor and not client-side flavor? It doesn't seem
terribly unlikely to me. This is a cute hack but it assumes that
everything in that directory can and should be built both ways.

regards, tom lane

Excerpts from Tom Lane's message of mar may 01 16:25:07 -0400 2012:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:

Instead, I thought this could easily be fixed by writing this:

%_srv.o: %.c %.o
$(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $< -o $@

A bit hacky, but should get quite robust results.

So basically to build the _srv.o file you first need to build the .o?
Since both files need to be built anyway, I don't think this is a
problem.

Are there, or might there be in the future, any "port" files that only
exist in server flavor and not client-side flavor? It doesn't seem
terribly unlikely to me. This is a cute hack but it assumes that
everything in that directory can and should be built both ways.

Well, right now the makefile has

OBJS = $(LIBOBJS) chklocale.o dirmod.o erand48.o exec.o fls.o inet_net_ntop.o \
noblock.o path.o pgcheckdir.o pg_crc.o pgmkdirp.o pgsleep.o \
pgstrcasecmp.o qsort.o qsort_arg.o sprompt.o thread.o

# foo_srv.o and foo.o are both built from foo.c, but only foo.o has -DFRONTEND
OBJS_SRV = $(OBJS:%.o=%_srv.o)

So yeah, all files are always built twice.

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.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.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

On Tue, May 1, 2012 at 10:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:

Instead, I thought this could easily be fixed by writing this:

%_srv.o: %.c %.o
     $(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $< -o $@

A bit hacky, but should get quite robust results.

So basically to build the _srv.o file you first need to build the .o?
Since both files need to be built anyway, I don't think this is a
problem.

Are there, or might there be in the future, any "port" files that only
exist in server flavor and not client-side flavor?  It doesn't seem
terribly unlikely to me.  This is a cute hack but it assumes that
everything in that directory can and should be built both ways.

Isn't that what backend/port/* is for?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus@hagander.net> writes:

On Tue, May 1, 2012 at 10:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Are there, or might there be in the future, any "port" files that only
exist in server flavor and not client-side flavor?

Isn't that what backend/port/* is for?

Ah, good point. Nevermind then.

regards, tom lane