Re: utils C files
От | Peter Eisentraut |
---|---|
Тема | Re: utils C files |
Дата | |
Msg-id | Pine.LNX.4.44.0207161941120.9047-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: utils C files (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: utils C files
|
Список | pgsql-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@gmx.net
В списке pgsql-patches по дате отправления: