* Stefano Lattarini wrote on Sun, Jun 20, 2010 at 11:07:01PM CEST:
> At Sunday 20 June 2010, Ralf Wildenhues wrote:
> > * 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?
Allow me to rephrase what I think. The required=gcc setting was
introduced several years ago for a handful of tests, in order to
avoid spurious testsuite failures with non-GCC compilers that either
had bugs, or that did not have some GCC-specific feature needed for
this particular test.
In the following eight or so years, it has been used more and more
widely; I am pretty sure that many of the tests requiring GCC do not
actually need gcc, but just need *any* working C compiler.
We should probably introduce a requirement c-compiler that doesn't
override the setting of $CC if any, precisely because it is good to be
able to run many Automake tests with other compilers, too. Catching
leftover files with distcheck is just one example where that is helpful.
With Fortran compilers, the issue is similar: e.g., allowing any Fortran
compiler for fort[45].test would probably expose us to bugs in Autoconf
and/or Libtool code. OTOH, silent5.test and silentf77.test look like
they could work with any Fortran compiler; not quite sure about
silentf90.test, it uses fixed format with a file name ending in .f90,
but that should be fixable in the test.
So, your proposed patch does some good and some bad. "Safer" in the
sense that we will probably see less failures in Automake's testsuite,
but unsafer in that we have less coverage of real situations that the
users of Automake may encounter with non-GCC compilers in their own
projects.
> > 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?
One problem with the more invasive change is that I would like to avoid
dependency inflation for the Automake package itself. What I mean by
this is the following: distributors typically try to build packages in a
mostly-minimal environment, where, since building Automake doesn't
require C++, Fortran compilers, yacc, lex, cscope, ctags, emacs, etc.,
their sandbox will typically not contain these things at all. If we
start adding checks for all of these tools to toplevel configure.ac, we
will make it harder for distributors to build Automake.
A first step that might seem easy to do would be to do the following:
introduce 'required=' keywords {C,C++,Fortran{,-77}}-compiler that
designate "I need a compiler of this type", rather than "I need the GNU
compiler for this language". As a first approximation, this could then
check either for presence of gcc/g++/gfortran/g77 but not set the $CC/...
variable (this is only to ensure that *some* compiler for the language
is available), or could assume that if the $CC/... variable has already
been set by the user, say, to something other than 'no', then this ought
to be a working compiler.
Then, we can adjust tests as appropriate, and change meaning of the g77
and gfortran requirements to do what your patch does, namely set $CC
etc. These requirements should also null $CFLAGS/... at least if both
CC and CFLAGS have been set before, to cope with the bug Peter stumbled
over.
> > 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.
See above for my reasoning.
> > 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.
Cheers,
Ralf
