Re: Make flex/bison checks stricter in Git trees

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make flex/bison checks stricter in Git trees
Date: 2016-09-27 13:49:20
Message-ID: 31139.1474984160@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> When running ./configure on a system without Flex/Bison its easy to miss the
> warning that flies past and then run into compilation error instead. When it
> happened to a colleague yesterday a brief discussion came to the conclusion
> that it would be neat it the flex and bison checks took the existence of the
> generated files into consideration.

> Attached patch scans for the generated files and iff flex or bison isnt found
> in a non-cross compilation build, errors out in case the generated filed dont
> exist while retaining the warning in case they do.

Not exactly convinced this is a good idea. What if the files exist but
are out of date? More generally, how much advantage is there really in
failing at configure rather than build time?

The subtext here is that I'm disinclined to load more behavior into
configure while we're waiting to see if cmake conversion happens.
That job is tough enough without the autoconf sources being more of
a moving target than they have to be.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2016-09-27 13:54:28 Re: PATCH: Exclude additional directories in pg_basebackup
Previous Message Michael Paquier 2016-09-27 13:48:24 Re: Password identifiers, protocol aging and SCRAM protocol