expected behavior for --with-cloog?

[Richard Guenther]

On Sun, Mar 28, 2010 at 5:25 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> On Sun, Mar 28, 2010 at 05:14:11PM +0200, Ralf Wildenhues wrote:
>> * Sebastian Pop wrote on Sun, Mar 28, 2010 at 03:38:49AM CEST:
>> > On Sat, Mar 27, 2010 at 12:17, Jack Howarth wrote:
>> > > My question was whether options like --with-cloog should cause configure
>> > > to exit as failed when they can't be satisfied rather than proceeding?
>>
>> > > 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.
>> >
>> > Fixed like this:
>> >
>> >         * configure.ac: Print "buggy but acceptable" when CLooG
>> >         revision is less than 9.
>> >         * configure: Regenerated.
>> >
>> > Passed bootstrap and test on amd64-linux.  Ok for trunk?
>>
>> This still doesn't error out when --with-cloog was explicitly passed but
>> not acceptable, right?
>>
>> > --- a/configure.ac
>> > +++ b/configure.ac
>> > @@ -1617,7 +1617,12 @@ if test "x$with_cloog" != "xno" -a "${ENABLE_CLOOG_CHECK}" = "yes"; then
>> >    #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 5
>> >    choke me
>> >    #endif
>> > -  ], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]); clooglibs= ; clooginc= ])
>> > +  ], AC_TRY_COMPILE([#include "cloog/cloog.h"],[
>>
>> Please wrap AC_TRY_COMPILE(...) in [ ] because as an argument to a macro
>> (in this case the outer AC_TRY_COMPILE) it should be quoted once.
>>
>> > +  #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 9
>> > +  choke me
>> > +  #endif
>> > +  ], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([buggy but acceptable])]),
>> > +  [AC_MSG_RESULT([no]); clooglibs= ; clooginc= ])
>>
>> I suppose Jack's request was that in this last 'no' branch, configure
>> errors out with AC_MSG_ERROR if $with_cloog != ''.
>>
>> >    CFLAGS="$saved_CFLAGS"
>> >  fi
>>
>> Cheers,
>> Ralf
>
> Ralf,
>   I was just trying to understand what the accepted practice is in
> FSF gcc was for such configuration flags. Since the compiler now requires
> gmp/mpfr/mpc to build, do we fail the build in configure if those libs
> don't exist in the correct versions? If so, shouldn't --with-cloog/--with-ppl
> be assumed as equivalent to --enable-graphite and fail the configuration
> if insufficient versions are present? It seems obvious that no one
> would use --with-cloog or --with-ppl unless they wanted graphite
> support so that silently failing to build graphite or building against
> incompatible versions of cloog/ppl is a bad thing.

Huh, well.  We don't have --enable-graphite, so what do you want in
case of --with-cloog but not --with-ppl?  I understood that both options
are to specify the cloog/ppl version to use.  They do not specify the
intent to enable graphite.

For LTO we have --enable-lto which will fail configure if a compatible
libelf is not detected (and we still have --with-libelf, which itself doesn't
cause errors if not --enable-lto is given).

Thus, rather than fiddling with --with-cloog or --with-ppl there should
be a --enable-graphite option to force graphite on.

But it's also that we are near a 4.5 release and the current configure
shipped with 4.4.x already.  So no need to fix anything in a rush.
Please.

Thanks,
Richard.

>           Jack
>
>