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.
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
* 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
* 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:
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
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/