Re: cvs build failure

Поиск
Список
Период
Сортировка
От Markus Bertheau
Тема Re: cvs build failure
Дата
Msg-id 1057100170.2509.78.camel@saphir
обсуждение исходный текст
Ответ на Re: cvs build failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: cvs build failure  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Список pgsql-hackers
В Срд, 02.07.2003, в 00:42, Tom Lane пишет:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Maybe make configure act as though bison is missing?  Not sure.  It
> >> seems like that could create unnecessary problems in other cases.
>
> > One trick would be to set YACC to some special value like
> > "bison.too.old" and test for that when YACC is actually called from the
> > Makefile.
>
> I kinda like Alvaro's suggestion of an --ignore-bison-version option
> to configure to suppress checking the version, but otherwise error out
> if we think bison is too old.
>
> The advantage to that is that you could manually override the automatic
> check if you had reason to know it was wrong (eg, you could see it'd
> misparsed the bison version string, or something).  Also, it'd make
> sense to include that option by default in RPM builds, where you'd know
> you had up-to-date bison output files already included in the SRPM.

But it seems weird to require a switch for the normal case, i.e. a
tarball build, and not require it for a cvs build. I don't see
overriding as an advantage, too, because misparsing of the bison version
string would just be a bug that had to be fixed, imo. You can as well
modify configure in that case to make it compile, and send the patch to
the bison version parser in afterwards.

Maybe add a comment to the Makefile where bison is called that gives a
hint to the user in case bison fails.

--
Markus Bertheau.
Berlin, Berlin.
Germany.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: cvs build failure
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: cvs build failure