Skip site navigation (1) Skip section navigation (2)

Re: pgxs and bison, flex

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgxs and bison, flex
Date: 2012-03-29 02:12:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> There are some extensions that build with pgxs that use bison and flex.
> Their makefiles are set up to use the variables BISON and FLEX that pgxs
> provides.  Except that that depends on how PostgreSQL was built.  A
> binary package that was built in a clean chroot would probably not have
> those variables set, because the programs were not present in the build
> process.  There have been a number of bugs related to those extensions
> because of that.

> I propose that we apply the attached patch to make sure those variables
> are set to a usable default value in any case.

Won't this break usages such as in contrib/cube?

cubeparse.c: cubeparse.y
ifdef BISON
	$(BISON) $(BISONFLAGS) -o $@ $<
	@$(missing) bison $< $@

IMO, people building distribution packages in clean chroots are best
advised to include bison and flex even if they're not strictly
necessary.  Otherwise the build could fall over unexpectedly and
unnecessarily, depending on file timestamps and other phase-of-the-moon
issues.  If the package maker has adopted that elementary bit of
self-defense, the whole thing is a non problem.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2012-03-29 02:33:04
Subject: Re: Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing
Previous:From: Tom LaneDate: 2012-03-29 02:02:45
Subject: Re: max_files_per_process ignored on Windows

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group