Re: gram.y=>preproc.y

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: gram.y=>preproc.y
Дата
Msg-id 7280.1226333017@sss.pgh.pa.us
обсуждение исходный текст
Ответ на gram.y=>preproc.y  (Michael Meskes <meskes@postgresql.org>)
Ответы Re: gram.y=>preproc.y  ("David E. Wheeler" <david@kineticode.com>)
Re: gram.y=>preproc.y  (Magnus Hagander <magnus@hagander.net>)
Re: gram.y=>preproc.y  (Michael Meskes <meskes@postgresql.org>)
Список pgsql-hackers
Michael Meskes <meskes@postgresql.org> writes:
> The attached version now is able to generate an ecpg parser without a single
> change in gram.y.

Sweet.

> Also included is a perl version of the script created by a2p
> and fixed by me. Unfortunately a2p did not generate working code, so I guess
> eventually we have to only work with the perl version. I guess a perl hacker
> can beautify the script quite a bit. 

We should probably standardize on the perl version, ugly or not, because
otherwise we'll have a difference in build process between Unix and
Windows machines.  Personally I don't really care how ugly it is as long
as no one has to look at it ;-) ... but if someone wants to beautify the
perl script they're surely welcome to do so.

A few notes:

* before committing we need to see the proposed diffs to the Makefiles
and the Windows build scripts.

* As-is, the first few lines of parse.pl contain an unportable hardwired
assumption about where the perl executable is.  I'd suggest removing
those lines and having the makefile call the script as
$(PERL) parse.pl ...

* Can we get a $PostgreSQL$ version identifier into each file that
will be added to CVS?
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: per-database locale: createdb switches
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: plperl needs upgrade for Fedora 10