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 sub
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
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
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 prep
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 doe
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 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 n
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.
>
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
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 ha
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: $(top_srcdir)/src/backend/pars
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)
Mi
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 t
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 everywh
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
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
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
--
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 beautif
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 scri
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 look
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
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
> even
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 ;-) .
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 p
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
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 a
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
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 expec
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
