Re: expected behavior for --with-cloog?

[Richard Guenther <richard dot guenther at gmail dot com>]

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
>
>