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

Excerpts from Tom Lane's message of mar may 01 16:25:07 -0400 2012:
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support