On 06/15/2012 07:16 AM, Timothy Madden wrote: >> >> How about the predefined programs ? >> >> AC_PROG_YACC might set YACC to 'bison -y', how would I check that 'bison >> -y' is found or is on path ? If AC_PROG_YACC set YACC to 'bison -y', then 'bison' is on PATH. Only if $YACC ends up as 'yacc' do you run the risk that AC_PROG_YACC didn't find anything. But since 'yacc' is required to be on all POSIX-y systems and is listed as one of the portable programs that the GNU Coding Standards states that you can assume to exist, this shouldn't matter in practice. > > I find that the following command > command -v bison -y > works as expected and returns 0 if bison is found or non-zero if there > is no bison. > > What do you know about the portability of `command` ? Can I use it in my > configure.ac ? Not portable. Sorry. > > Or is there a better way to exit after AC_PROG_YACC if bison is not > found ? Or to exit if AC_PROG_CXX does not find a C++ compiler ? Based on the documentation, AC_PROG_YACC looks for bison, and falls back to yacc (but without checking for yacc). So the test would be: AC_PROG_YACC if test "$YACC" = yacc; then AC_MSG_ERROR([this project insists on using bison instead of yacc]) fi Based on the documentation in current autoconf, AC_PROG_CXX looks for several compilers, then falls back to 'g++'; but it also sets GXX to yes if it found a working g++ (as opposed to leaving GXX alone when using the fallback value); other versions of autoconf and/or combinations with automake or libtool have set GXX to 'no' rather than 'g++' as a more useful fallback when no C++ compiler is present. So that would translate to something like: AC_PROG_CXX if test "$CXX" = no || test "$CXX:$GXX" = "g++:"; then AC_MSG_ERROR([no C++ compiler found]) fi > >> >> And really, is there no support in autoconf itself for this ? > > Is there no flag or option to make the resulting configure exit > automatically if any of the checks fail ? No, because blindly failing is not helpful to people that can get by without yacc or c++. In other words, the default behavior is useful to some packages, and the building blocks are in place for you to manually fail with your own AC_MSG_ERROR if you don't like the default; but failing by default would prevent the packages that can fall back to useful behavior without the tools. It's not that much harder to add your own AC_MSG_ERROR condition after testing for a tool. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
