Re: [HACKERS] Re: setsockopt(SO_REUSEADDR) (Re: Call for porting reports)
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Re: setsockopt(SO_REUSEADDR) (Re: Call for porting reports) |
Дата | |
Msg-id | Pine.LNX.4.21.0004121431200.358-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: setsockopt(SO_REUSEADDR) (Re: Call for porting reports) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-ports |
Tom Lane writes: > "Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes: > > 1) psql cannot be made since perl is used to generate sql_help.h. There is > > no perl on this machine. So configure doesn't help if perl is used anyway. > > sql_help.h is (or should be) part of the distribution tarball. Was it > not present, or perhaps out-of-date? In any case the Makefile for psql > looks like it will not try to regenerate sql_help.h unless configure > found perl. That was the idea but it doesn't quite work this way. The variable PERL is hard-coded to be "perl" in Makefile.global.in, no testing is actually done. (Wasn't my idea.) This will essentially prevent building psql on machines without Perl *if sql_help.h needs to be rebuilt* (which it shouldn't). This leads to a second problem, however. There's a subtle difference between targets of the form sql_help.h: # no dependencies, no action and sql_help.h: ; # no dependencies, "do nothing" as action The latter would be the righter thing to do because the former will consider sql_help.h updated whenever the rule is run. This will in turn lead to recompilation of help.c and thus psql for every make run. I just learned that the other day. I have a fix for both issues (the first involves AC_CHECK_PROGS, the second is obvious), should I go for it? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-ports по дате отправления: