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

[Stefano Lattarini]

At Monday 21 June 2010, Ralf Wildenhues wrote:
> * 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.
Absolutely correct.

> 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. 
I heartily agree.

> With Fortran compilers, the issue is similar:
I agree again.

> 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.
Hmm... Well, you seem to be right.

> > > 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.
No no no, I haven't exaplained myself correctly: Automake shouldn't 
*depend* on any of those tools, it should just *check for them*,
and take note of what's available and what's not; so that the
tests requiring missing tools could be gracefully and correctly
skipped.

A sketched example:

  - in configure:
      AC_PATH_PROG([PYTHON], [python], [])
    (or more complex stuff with AC_PATH_PROGS_FEATURE_CHECK,
    to ensure we have all the features we need)

  - in defs.in:
      ...
      PYTHON='@PYTHON@'
      ...
      for tool in $required; do 
        case $tool in
          ...
          python)
            test -n "$PYTHON" || Exit 77
          ...        
  
  - in foo-python.test:
      required=python
      ./defs || Exit 1
      ...
      ./configure PYTHON="$PYTHON" ...
      ...

>  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.
I want to stress that we should not depend on those tools to build,
distribute or install automake.  That would be a royally bad idea.

> 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".
Yes, that was my idea too.  Clearly I failed miserably in 
communicating it  :-(

>  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.
I like this first step.  I might come up on a patch along those lines in a few
days (if you don't beat me ;-)

> 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.
Yes.  Maybe we could clobber CFLAGS uncoditionally if gcc is required,
and export CFLAGS=${GCC_CFLAGS-}, so that the user can override
it easily.  WDYT?

> > > 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.
I meant: "this makes my point of improving handling of requirements
in tests/defs stronger".  Again a communication failure on my part :-(

In conclusion: 
 1. we violently agree, and
 2. I should work on my poor communication skills.

Regards,
     Stefano