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@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026