automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix code for requiring gfortran and g77 in tests.


From: Stefano Lattarini
Subject: Re: [PATCH] Fix code for requiring gfortran and g77 in tests.
Date: Sun, 20 Jun 2010 23:07:01 +0200
User-agent: KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.4; i686; ; )

At Sunday 20 June 2010, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Sun, Jun 13, 2010 at 10:03:33PM CEST:
> > Another improvements to 'tests/defs', factored out from my
> > on-going refactoring of test scripts setup.  This time it is
> > (should be) a real improvement, not just a cosmetic one.
> 
> I see your point, but do you have a system or an environment where
>  it makes a difference, and for which Automake tests?
Not that I know of.  But this change makes the requiring of gfortran 
and g77 more consistent with that of gcc or g++.

>  AC_PROG_{F77,FC} should be trying g77/gfortran first,
>  and if you have $F77 or $FC set, I assume they point to
>  decent compilers.
The same could be said for AC_PROG_CC (it tries gcc first, and it
assumes that $CC points to a decent C compiler if it's set).  Then why 
are we exporting CC=gcc in 'tests/defs' if gcc is in $required?  I'd 
say: for clarity and safety.  WDYT?

> More generally, we really actually would like to be able to run the
> tests with various different compilers.
>
Well, I think that ideally we should check, in Automake's own configure 
script, for the various compilers, programs and/or tools used by our 
testsuite, and AC_SUBST them in defs.in, like we do now for e.g.
$TEX (where an emtpy value means "no such tool available").  Or better 
again, we might AC_SUBST them *and* lett them be overridable from the 
environment in a namespace-safe manner, as in e.g.:
  EGREP=${AM_TESTSUITE_EGREP-'@EGREP@'}
  CC=${AM_TESTSUITE_CC-'@CC@'}
  GCC=${AM_TESTSUITE_GCC-'@GCC@'}
  ...

But this is a far more invasive change, that should be discussed and 
planned carefully before being implemented, and tested well 
thereafter.  For the moment, I'd content myself with the attached 
"consistency" patch. Opinions?

> The 'gcc' requirement is
>  fairly strong and limiting; in many cases, we might be able to get
>  by with having any working C compiler.
Yes, and this makes my point above stronger IMO.

>  OTOH, we don't really want
>  to have to expose us to bugs/limitations in Autoconf's macros too
>  much that happen to not support some compiler well yet.
> 
> That said, I have a patch for the Autoconf testsuite to get some
>  more exposure for the Fortran macros, which I guess I should post
>  there for discussion.
More coverage is IMHO always good . Thanks!
I'll step in there if I have anything interesting to say or suggest, 
but don't expect much (I'm fairly ignorant about the Fortran support 
in Autoconf, and I'm very ignorant about the whole Autotest stuff).

Regards,
    Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]