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
