Thread: port _srv.o makefile rules don't observe dependency tracking
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?
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.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
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