Skip site navigation (1) Skip section navigation (2)

Re: utils C files

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: utils C files
Date: 2002-07-16 21:57:18
Message-ID: Pine.LNX.4.44.0207161941120.9047-100000@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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.

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.

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

-- 
Peter Eisentraut   peter_e(at)gmx(dot)net


In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2002-07-16 21:57:37
Subject: Re: Future of src/utils
Previous:From: Peter EisentrautDate: 2002-07-16 21:56:37
Subject: Re: getopt_long search in configure

pgsql-patches by date

Next:From: Bruce MomjianDate: 2002-07-17 03:03:27
Subject: Re: utils C files
Previous:From: Bruce MomjianDate: 2002-07-16 17:36:41
Subject: Re: minor GEQO fixes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group