Thread: make caught doing what configure should...
Shouldn't configure look for the pre-generated file when the test for bison fails? Is 'test -f' portable? Is this the right file to patch? I'm not an autoconf person. :) Index: configure.in =================================================================== RCS file: /home/pgcvs/pgsql/configure.in,v retrieving revision 1.111 diff -c -r1.111 configure.in *** configure.in 2001/03/20 23:35:18 1.111 --- configure.in 2001/03/23 11:32:16 *************** *** 627,641 **** AC_CHECK_PROGS(PERL, perl) AC_CHECK_PROGS(YACC, ['bison -y']) ! if test -z "$YACC"; then ! AC_MSG_WARN([ ! *** Without Bison you will not be able to build PostgreSQL from CVS or ! *** change any of the parser definition files. You can obtain Bison from ! *** a GNU mirror site. (If you are using the official distribution of ! *** PostgreSQL then you do not need to worry about this because the Bison ! *** output is pre-generated.) To use a different yacc program (possible, ! *** but not recommended), set the environment variable YACC before running ! *** 'configure'.]) fi AC_SUBST(YFLAGS) --- 627,640 ---- AC_CHECK_PROGS(PERL, perl) AC_CHECK_PROGS(YACC, ['bison -y']) ! if test -z "$YACC" && test ! -f src/backend/parser/gram.c ; then ! AC_MSG_ERROR([ ! *** 'bison' is missing on your system. It is needed to create the ! *** file 'gram.c'. You can either get bison from a GNU mirror site ! *** or download an official distribution of PostgreSQL, which contains ! *** pre-packaged bison output. ! *** To use a different yacc program (possible, but not recommended), set ! *** the environment variable YACC before running 'configure'.]) fi AC_SUBST(YFLAGS) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.
* Tom Lane <tgl@sss.pgh.pa.us> [010323 08:47] wrote: > Alfred Perlstein <bright@wintelcom.net> writes: > >> Besides, I think the warning message is appropriate in any case, since > >> it lets bison-less people know that they had better not blow away gram.c > >> or hack on gram.y. > > > Er, not really, it (the warning) gets blown away by all the rest > > of the ./configure output. It might as well error out, not just > > warn, then you can actually see the message. > > Erroring out would be completely inappropriate unless we had made an > *accurate* check that gram.c was out of date. I think that's probably > a cure worse than the disease; we risk unnecessary configure failures > to gain, well, not a lot. You're right that configure's output is too > chatty for many people; but isn't there a "--quiet" option? Seems like > that's what they should be using if they don't want to see details. GRR! :) The make will still bomb out. It's my opinion that if the configure script detects a situation that will make compilation impossible _it_ should abort, not proceed to allow the user to run make when it knows it will not succeed. I mean it wouldn't make much sense for it to give a warning about all variants of "fork()" not existing would it? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/
Alfred Perlstein <bright@wintelcom.net> writes:
> Shouldn't configure look for the pre-generated file when the test for
> bison fails?
No, I don't think so. At least not that way: what you'd need to
discover is not only whether gram.c exists but whether it is newer
than all its prerequisite files.
Besides, I think the warning message is appropriate in any case, since
it lets bison-less people know that they had better not blow away gram.c
or hack on gram.y.
regards, tom lane
Alfred Perlstein <bright@wintelcom.net> writes:
> It's my opinion that if the configure script detects a situation
> that will make compilation impossible _it_ should abort,
But the test you proposed is not adequate to determine whether make
will bomb out.
regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [010323 08:40] wrote: > Alfred Perlstein <bright@wintelcom.net> writes: > > Shouldn't configure look for the pre-generated file when the test for > > bison fails? > > No, I don't think so. At least not that way: what you'd need to > discover is not only whether gram.c exists but whether it is newer > than all its prerequisite files. > > Besides, I think the warning message is appropriate in any case, since > it lets bison-less people know that they had better not blow away gram.c > or hack on gram.y. Er, not really, it (the warning) gets blown away by all the rest of the ./configure output. It might as well error out, not just warn, then you can actually see the message. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/
Alfred Perlstein <bright@wintelcom.net> writes:
>> Besides, I think the warning message is appropriate in any case, since
>> it lets bison-less people know that they had better not blow away gram.c
>> or hack on gram.y.
> Er, not really, it (the warning) gets blown away by all the rest
> of the ./configure output. It might as well error out, not just
> warn, then you can actually see the message.
Erroring out would be completely inappropriate unless we had made an
*accurate* check that gram.c was out of date. I think that's probably
a cure worse than the disease; we risk unnecessary configure failures
to gain, well, not a lot. You're right that configure's output is too
chatty for many people; but isn't there a "--quiet" option? Seems like
that's what they should be using if they don't want to see details.
regards, tom lane
Alfred Perlstein writes: > Shouldn't configure look for the pre-generated file when the test for > bison fails? configure doing what make should...? This approach is pretty standard in autoconfiscated packages. Maybe a tad noisy, but if you're using CVS, that's what you get. > Is 'test -f' portable? Yes. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
* Peter Eisentraut <peter_e@gmx.net> [010324 03:16] wrote: > Alfred Perlstein writes: > > > Shouldn't configure look for the pre-generated file when the test for > > bison fails? > > configure doing what make should...? > > This approach is pretty standard in autoconfiscated packages. Maybe a tad > noisy, but if you're using CVS, that's what you get. Bah, just remove the test for bison from configure then, there's no point to it at all! -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/