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

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

From
Peter Eisentraut
Date:
There is this rule in src/port/Makefile:

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

But this rule doesn't observe dependency tracking, so if you change a
header file, these files won't get build as necessary.  This is the only
case in the source tree where this happens, because (after a few more
trivial fixups I have made recently) everything else uses the default
%.c -> %.o rule.

I have thought for a long time about how to refactor the dependency
tracking logic from Makefile.global so that it can support this outlier,
but all solutions ended up more complex than I would have liked.
(Something like bundling up the entire logic into make functions and
calling it from various places.)

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.

Comments, other ideas?




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

From
Alvaro Herrera
Date:
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


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

From
Tom Lane
Date:
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


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

From
Alvaro Herrera
Date:
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.opgmkdirp.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


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

From
Tom Lane
Date:
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


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

From
Magnus Hagander
Date:
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/


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

From
Tom Lane
Date:
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