Re: utils C files

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > > Can you point to one example of such an inconsistency? I can't find one.
> >
> > Sure, interfaces/libpq had:
> >
> > OBJS= fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o \
> > pqexpbuffer.o dllist.o md5.o pqsignal.o fe-secure.o \
> > $(INET_ATON) $(SNPRINTF) $(STRERROR)
> >
> > while psql/Makefile had what I think you wanted:
>
> Note that the libpq makefile goes through trouble to link the inet_aton.c
> file into the current directory, so this example doesn't count.

Well, the code is:

# this only gets done if configure finds system doesn't have inet_aton()
inet_aton.c: $(backend_src)/port/inet_aton.c
rm -f $@ && $(LN_S) $< .

How is this any better than just mentioning the *.o file and letting the
default rules compile it. I don't understand how linking to the current
directory gets us anything. Now, if you did a 'make -C dir target' that
would be different.

In fact, with the lib idea dead, if there are special rules for for
certain port/*.o files, we should put those rules in Makefile.global and
let all the code use it. That way, we defined it in one place, but can
use the object file anywhere.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026