Re: [PATCHES] Fix spurious failures of some tests `silent*.test' with SunStudio Fortran

[Ralf Wildenhues]

* Stefano Lattarini wrote on Wed, Nov 17, 2010 at 07:25:32PM CET:
> On Wednesday 17 November 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Wed, Nov 17, 2010 at 03:25:02PM CET:
> > >    F77    bar.o
> > >  NOTICE: Invoking /opt/SunStudio/sunstudio12.1/prod/bin/f90 -f77 
> > > -ftrap=%none -g -c -o bar.o bar.f

> > > Now, these failure are clearly spurious, and easy worked around,
> > > so I'd like to apply the attached patches to temporary bugfixing
> > > branches, and merge them to maint.
> > 
> > Well, the question that comes to mind is, is there a flag with which we
> > could silence the compiler?
> >
> Yes: `-silent'.  But testing to see if it's supported would probably
> be more complex than just filtering out the offending messages... hmm...
> unless we hack the configure.in to do the testing for us, which shouldn't
> be hard to do.  Do you want me to try that route and see how it works?

I haven't made up my mind yet.  At the moment I'm trying to find out
whether it is suitable or desirable for the silent-rules option to
trigger configure checks that set additional flags like -silent if
verbose mode is not enabled.

If we go this way, we shouldn't just do it for this one compiler.
I know at least two more: another Fortran compiler, and MSVC, where
this issue came up before already.  A survey about other compilers
would be good, before implementing something along these lines.

> > The user might just not want to read that NOTICE.
> > 
> > If not, then I'd squash the two patches together (is there a point in
> > keeping them separate?),
> >
> Well, they fix bugs introduced in two different commits, so they should
> be applied to different bug-fixing branches IMHO.

However you like.  I wouldn't call this a bug in the commit though,
rather a bug in the compiler which we work around.

> > and relax the sed pattern to kill all lines matching '^NOTICE:'.
> >
> I can amend both the patches to do so.

Yes, I think for the moment that is the best route.

> > Even that might eventually not be enough with localization,
> >
> I don't think that's an issue, since the SunStudio `f77' is a simple
> shell script wrapping the "real" compiler.  No i18n/l10n involved.

So?  The next version might change.  Let's not narrow our minds for one
particular compiler (version) only.  That is not maintainable.  We only
do such things in Libtool because for shared library semantics, there is
often no other way.

> > but at least then you aren't relying on specific compiler flags that
> > might not be valid with a different compiler version, or
> > different flags in $FCFLAGS or $FFLAGS.

Cheers,
Ralf