Re: utils C files - Mailing list pgsql-patches

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