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
True, that will help a lot.
Peter Eisentraut peter_e(at)gmx(dot)net
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2002-07-16 21:57:37|
|Subject: Re: Future of src/utils|
|Previous:||From: Peter Eisentraut||Date: 2002-07-16 21:56:37|
|Subject: Re: getopt_long search in configure|
pgsql-patches by date
|Next:||From: Bruce Momjian||Date: 2002-07-17 03:03:27|
|Subject: Re: utils C files|
|Previous:||From: Bruce Momjian||Date: 2002-07-16 17:36:41|
|Subject: Re: minor GEQO fixes|