On Thu, Nov 13, 2008 at 03:57:49PM -0500, Tom Lane wrote:
Michael Meskes [EMAIL PROTECTED] writes:
That's what I did first, but Magnus had a good reasoning to not keep
preproc.y
if we keep preproc.c in our tarball. And I agreed that there doesn't seem
to be
an advantage.
Other than
On Thu, Nov 13, 2008 at 03:10:04PM -0500, Tom Lane wrote:
VPATH build. (Parts of this patch have that right and part don't.
You might want to test in a VPATH build before committing.)
Did that and fixed the remaining problems. Attached you'll find the latest
version. I already committed the
Michael Meskes wrote:
+$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y
+ $(PERL) $(srcdir)/parse.pl $(srcdir) $ $@
Why are you passing $(srcdir) as a parameter here? It doesn't look like
the script uses it at all, or does it?
--
Alvaro Herrera
On Fri, Nov 14, 2008 at 09:03:34AM -0300, Alvaro Herrera wrote:
+$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y
+ $(PERL) $(srcdir)/parse.pl $(srcdir) $ $@
Why are you passing $(srcdir) as a parameter here? It doesn't look like
the script uses it at all, or does it?
Michael Meskes [EMAIL PROTECTED] writes:
Does anyone see a problem with these changes? Or else I will commit.
preproc.y should be removed by make maintainer-clean. For consistency
it probably ought to be listed in the distprep target too, even though
it would be indirectly updated by the
Michael Meskes wrote:
Does anyone see a problem with these changes? Or else I will commit.
FWIW, I have looked at this a bit. I want to refactor it at some stage
because it's ugly and fragile and rather obtuse, but the refactoring
won't be happening for a while.
cheers
andrew
On Fri, Nov 14, 2008 at 10:44:08AM -0500, Tom Lane wrote:
preproc.y should be removed by make maintainer-clean. For consistency
it probably ought to be listed in the distprep target too, even though
it would be indirectly updated by the preproc.c target. I suspect it
would be a good idea to
Michael Meskes [EMAIL PROTECTED] writes:
Added.
Looks alright to me now --- you might as well commit and let the
buildfarm find any remaining problems.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
since my last email seems to have disappeared, here we go again. Here's my
current patch that includes the changes to the build system. Thanks to Magnus
for the Windows part.
Comments anyone?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael Meskes [EMAIL PROTECTED] writes:
since my last email seems to have disappeared, here we go again. Here's my
current patch that includes the changes to the build system. Thanks to Magnus
for the Windows part.
Comments anyone?
+ $(srcdir)/preproc.y:
Michael Meskes [EMAIL PROTECTED] writes:
That's what I did first, but Magnus had a good reasoning to not keep preproc.y
if we keep preproc.c in our tarball. And I agreed that there doesn't seem to
be
an advantage.
Other than whether it *works*, you mean?
make will not be happy if it has a
On Thu, Nov 13, 2008 at 03:10:04PM -0500, Tom Lane wrote:
clean distclean:
! rm -f keywords.c *.o ecpg$(X) preproc.y
Actually, we want to fix it so that preproc.y is treated like preproc.c,
ie, it's part of the shipped tarballs even though it's no longer in CVS.
That's what I did
On Mon, Nov 10, 2008 at 09:38:58AM -0800, David E. Wheeler wrote:
I'd be happy to, but I haven't really been following this thread. What
does it do, and how do I make sure it continues to work as I refactor
it?
Just run parse.pl pgsql/src/backend/parser/gram.y preproc.y and compare the
On Mon, Nov 10, 2008 at 11:03:37AM -0500, Tom Lane wrote:
* before committing we need to see the proposed diffs to the Makefiles
and the Windows build scripts.
Sure. I just committed the generated preproc.y file to see how it goes through
the buildfarm. I prefer to see the file is okay
The attached version now is able to generate an ecpg parser without a single
change in gram.y. 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
On Nov 10, 2008, at 8:03 AM, Tom Lane wrote:
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 ;-)
Michael Meskes [EMAIL PROTECTED] 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
David E. Wheeler wrote:
On Nov 10, 2008, at 8:03 AM, Tom Lane wrote:
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
Andrew Dunstan [EMAIL PROTECTED] writes:
I have had a quick look at it. The perl is more than ugly - it's
unmaintainable IMNSHO. It violates perl best practice in many ways, and
reflects the age of the a2p utility quite badly.
There is no guarantee that the script won't have to be looked
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have had a quick look at it. The perl is more than ugly - it's
unmaintainable IMNSHO. It violates perl best practice in many ways, and
reflects the age of the a2p utility quite badly.
There is no guarantee that the
Tom Lane wrote:
Michael Meskes [EMAIL PROTECTED] writes:
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
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to un-
uglify this.
My Perl is excellent, but my awk is remedial. What part does awk play?
Best,
David
--
David E. Wheeler wrote:
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to
un-uglify this.
My Perl is excellent, but my awk is remedial. What part does awk
Andrew Dunstan wrote:
David E. Wheeler wrote:
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to
un-uglify this.
My Perl is excellent, but my
Michael Meskes [EMAIL PROTECTED] writes:
... What still needs to be done is beautifying the script (I don't like
all those static declarations) and removing the remaining changes to gram.y.
There are only two left (variable handling on quite some places and
prepared_name twice).
Adding a new
On Tue, Nov 04, 2008 at 01:03:44PM -0500, Tom Lane wrote:
I'm quite unhappy with the invasiveness of the proposed gram.y changes.
Keep in mind that this is work in progress. I'm still working on this stuff and
yes, I'm trying to simplify things.
The @ECPG annotations are bad enough, but why
Michael Meskes [EMAIL PROTECTED] writes:
On Mon, Nov 03, 2008 at 07:10:01PM -0500, Tom Lane wrote:
(You might need to compress the files if the message comes to more than
100-some KB. Also, given that preproc.y can be generated so easily, it
could just be left out.)
I did this this time.
Michael Meskes [EMAIL PROTECTED] writes:
I finally have a working version. Please have a look at the attached files
including a changed version of gram.y and and automatically created version of
preproc.y. To recreate just run awk -f parse.awk gram.y preproc.y.
Ping? I've been expecting a
I finally have a working version. Please have a look at the attached files
including a changed version of gram.y and and automatically created version of
preproc.y. To recreate just run awk -f parse.awk gram.y preproc.y.
Is it okay to change gram.y this way? It does run the regression suite
29 matches
Mail list logo
