On Sat, Mar 27, 2010 at 07:56:14AM +0100, Ralf Wildenhues wrote:
> Hello Jack,
>
> * Jack Howarth wrote on Fri, Mar 26, 2010 at 01:13:16AM CET:
> > While testing a patch to update the minimum version
> > of cloog-ppl in gcc trunk...
>
> > --- configure.ac (revision 157732)
> > +++ configure.ac (working copy)
> > @@ -1612,9 +1612,9 @@
> > if test "x$with_cloog" != "xno" -a "${ENABLE_CLOOG_CHECK}" = "yes"; then
> > saved_CFLAGS="$CFLAGS"
> > CFLAGS="$CFLAGS $clooginc $gmpinc $pplinc"
> > - AC_MSG_CHECKING([for version 0.15.5 (or later revision) of CLooG])
> > + AC_MSG_CHECKING([for version 0.15.9 (or later revision) of CLooG])
> > AC_TRY_COMPILE([#include "cloog/cloog.h"],[
> > - #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 ||
> > CLOOG_VERSION_REVISION < 5
> > + #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 ||
> > CLOOG_VERSION_REVISION < 9
> > choke me
> > #endif
> > ], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]); clooglibs= ; clooginc=
> > ])
> >
> > I noticed that this test only returns...
> >
> > checking for version 0.15.9 (or later revision) of CLooG... no
> >
> > for...
> >
> > ../gcc-4.5-20100325/configure --prefix=/sw --prefix=/sw/lib/gcc4.5
> > --mandir=/sw/share/man --infodir=/sw/share/info
> > --enable-languages=c,c++,fortran,objc,obj-c++,java \
> > --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw
> > --with-mpc=/sw --with-system-zlib \
> > --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
> > --disable-libjava-multilib --enable-checking=release
> >
> > ...when a cloog-ppl earlier than 0.15.9 is installed. Shouldn't configure
> > fail
> > outright in this case since the user obviously intended cloog to be used?
> > Currently
> > configure proceeds to set up a build without graphite support.
>
> Well, what does config.log tell you why it was not detected?
>
> Cheers,
> Ralf
Ralf,
It is detected as being insufficient, hence the...
> > checking for version 0.15.9 (or later revision) of CLooG... no
My question was whether options like --with-cloog should cause configure
to exit as failed when they can't be satisfied rather than proceeding?
Does a failure to meet the required gmp/mpfr/mpc version requirements
behave the same way or do they abort the configure process?
Jack
ps I am considering the case of explicitly passing a --with-xxxx option
as opposed to a library dependency which is being automatically checked
by configure.
