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
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 |