Thread: Re: [COMMITTERS] pgsql: Remove all traces that suggest that a non-Bison yacc might be

Peter Eisentraut wrote:
> Log Message:
> -----------
> Remove all traces that suggest that a non-Bison yacc might be supported, and 
> change build system to use only Bison.  Simplify build rules, make file names 
> uniform.  Don't build the token table header file where it is not needed.

I'm finding that this patch is needed to make this build on VPATH:

Index: src/backend/parser/Makefile
===================================================================
RCS file: /cvsroot/pgsql/src/backend/parser/Makefile,v
retrieving revision 1.47
diff -c -p -r1.47 Makefile
*** src/backend/parser/Makefile 29 Aug 2008 13:02:32 -0000      1.47
--- src/backend/parser/Makefile 29 Aug 2008 16:17:16 -0000
*************** subdir = src/backend/parser
*** 10,16 **** top_builddir = ../../.. include $(top_builddir)/src/Makefile.global 
! override CPPFLAGS := -I$(srcdir) $(CPPFLAGS)  OBJS= analyze.o gram.o keywords.o parser.o parse_agg.o parse_clause.o \
     parse_expr.o parse_func.o parse_node.o parse_oper.o parse_relation.o \
 
--- 10,16 ---- top_builddir = ../../.. include $(top_builddir)/src/Makefile.global 
! override CPPFLAGS := -I$(srcdir)/.. $(CPPFLAGS)  OBJS= analyze.o gram.o keywords.o parser.o parse_agg.o
parse_clause.o\       parse_expr.o parse_func.o parse_node.o parse_oper.o parse_relation.o \
 


The problem is that keywords.c is #including "parser/gram.h" but since
we're doing a -I.../backend/parser then it doesn't find it.

I don't understand why it was working previously.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> I'm finding that this patch is needed to make this build on VPATH:

I cannot reproduce any problem with a vpath build.  Make sure you have 
really cleaned the source tree from previous rounds.  Some of the files 
involved are symlinks, which might confuse make.

> Index: src/backend/parser/Makefile
> ===================================================================
> RCS file: /cvsroot/pgsql/src/backend/parser/Makefile,v
> retrieving revision 1.47
> diff -c -p -r1.47 Makefile
> *** src/backend/parser/Makefile 29 Aug 2008 13:02:32 -0000      1.47
> --- src/backend/parser/Makefile 29 Aug 2008 16:17:16 -0000
> *************** subdir = src/backend/parser
> *** 10,16 ****
>   top_builddir = ../../..
>   include $(top_builddir)/src/Makefile.global
>   
> ! override CPPFLAGS := -I$(srcdir) $(CPPFLAGS)
>   
>   OBJS= analyze.o gram.o keywords.o parser.o parse_agg.o parse_clause.o \
>         parse_expr.o parse_func.o parse_node.o parse_oper.o parse_relation.o \
> --- 10,16 ----
>   top_builddir = ../../..
>   include $(top_builddir)/src/Makefile.global
>   
> ! override CPPFLAGS := -I$(srcdir)/.. $(CPPFLAGS)
>   
>   OBJS= analyze.o gram.o keywords.o parser.o parse_agg.o parse_clause.o \
>         parse_expr.o parse_func.o parse_node.o parse_oper.o parse_relation.o \

This would create a reference to src/backend, but no .h file should ever 
live there.

> The problem is that keywords.c is #including "parser/gram.h" but since
> we're doing a -I.../backend/parser then it doesn't find it.
> 
> I don't understand why it was working previously.

I think the -I$(srcdir) is actually useless, and you are just 
accidentally adapting it for your workaround.

Peter Eisentraut <peter_e@gmx.net> writes:
> I cannot reproduce any problem with a vpath build.  Make sure you have 
> really cleaned the source tree from previous rounds.  Some of the files 
> involved are symlinks, which might confuse make.

"make maintainer-clean" before pulling this update would be a good idea,
else you're going to have junk laying about in your source tree.

> I think the -I$(srcdir) is actually useless, and you are just 
> accidentally adapting it for your workaround.

Yeah, it should be finding the symlink in $builddir/src/include/parser.

If the -I isn't needed, shouldn't we get rid of it?
        regards, tom lane

Peter Eisentraut wrote:
> Alvaro Herrera wrote:
>> I'm finding that this patch is needed to make this build on VPATH:
>
> I cannot reproduce any problem with a vpath build.  Make sure you have  
> really cleaned the source tree from previous rounds.  Some of the files  
> involved are symlinks, which might confuse make.

Hmm, yeah, I just manually deleted everything mentioned in .cvsignore
and it works now.

It seems there's no way to do this directly.  I have this:
   find . -name .cvsignore | while read line   do       dir=$(dirname $line)       cd $dir       rm -fv `cat
.cvsignore`      cd "$OLDPWD"   done
 

Could we have a target in the root Makefile for this?  Right now it
bails out with

$ make distclean
You need to run the 'configure' program first. See the file
'INSTALL' for installation instructions.
make: *** [distclean] Erreur 1

>>   ! override CPPFLAGS := -I$(srcdir)/.. $(CPPFLAGS)
>
> This would create a reference to src/backend, but no .h file should ever  
> live there.

Right -- the point is that keywords.c has
#include "parser/gram.h"
so if you start from src/backend, then the file is found.

>> The problem is that keywords.c is #including "parser/gram.h" but since
>> we're doing a -I.../backend/parser then it doesn't find it.
>>
>> I don't understand why it was working previously.
>
> I think the -I$(srcdir) is actually useless, and you are just  
> accidentally adapting it for your workaround.

Could be.  Maybe we could just remove the line to avoid future
confusion.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > I cannot reproduce any problem with a vpath build.  Make sure you have 
> > really cleaned the source tree from previous rounds.  Some of the files 
> > involved are symlinks, which might confuse make.
> 
> "make maintainer-clean" before pulling this update would be a good idea,
> else you're going to have junk laying about in your source tree.

Ah, so that's the necessary trick.  Thanks.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support