Re: utils C files

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Well, the actual problem was that there was inconsistency in the way
> > things where handled, e.g. some had their own rules for making the *.o
> > files if the *.o files were out of the current directory, other didn't.
> > I can change it but it has to be consistent. What do you suggest?
>
> 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:

OBJS=command.o common.o help.o input.o stringutils.o mainloop.o \
copy.o startup.o prompt.o variables.o large_obj.o print.o describe.o \
sprompt.o tab-complete.o mbprint.o

all: submake psql

ifdef STRDUP
OBJS+=$(top_builddir)/src/utils/strdup.o

$(top_builddir)/src/utils/strdup.o:
$(MAKE) -C $(top_builddir)/src/utils strdup.o
endif

ifdef STRERROR
OBJS+=$(top_builddir)/src/backend/port/strerror.o

$(top_builddir)/src/backend/port/strerror.o:
$(MAKE) -C $(top_builddir)/src/backend/port strerror.o
endif

ifdef SNPRINTF
OBJS+=$(top_builddir)/src/backend/port/snprintf.o

$(top_builddir)/src/backend/port/snprintf.o:
$(MAKE) -C $(top_builddir)/src/backend/port snprintf.o
endif

Here we see SNPRINTF done in two different ways. I think the library
file is the way to go anyway. We compile it once, and use it whenever
we need it. Clean.

> The rule of thumb is that rules involving the C compiler should only use
> files in the current directory. Otherwise you don't know where those
> files are going to end up.

Sure.

> > > A secondary objection is that I've been meaning to replace configure
> > > checks of the form
> > >
> > > AC_CHECK_FUNCS(inet_aton, [], INET_ATON='inet_aton.o')
> > > AC_SUBST(INET_ATON)
> > >
> > > with one integrated macro, which doesn't work if we have to encode the
> > > path into configure.
> >
> > The path is only the thing we assign to the variable. I can't see how
> > that effects the configure script.
>
> What I want this to read in the end is
>
> PGAC_SOME_MACRO([func1 func2 func3])
>
> > Actually, once we move stuff into the same directory, it will not
> > matter.
>
> True, that will help a lot.

Heck, soon configure is only going to control what gets put in the
libport.a file and that's it.

--
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