[GRASS-dev] BLAS/LAPACK detection (was: configure fails)

[Brad Douglas]

On Thu, 2007-09-27 at 15:26 +0100, Glynn Clements wrote:
> Brad Douglas wrote:
> 
> > > I see that this is related to Brad's and Markus' changes of today. Does
> > > this mean that the fortran compiler in mingw is not sufficient ? Or is
> > > this an error in the configure file ? Also, do I absolutely need a fortran
> > > complier ?
> > > For what ?
> > 
> > For now, no, you don't need a working Fortran compiler.
> > 
> > Fortran is required for certain versions of BLAS/LAPACK.  There are
> > other equivalents that may be more forgiving like ATLAS, PhiPACK,
> > CBLAS/CLAPACK.
> > 
> > My changes were meant to expand BLAS/LAPACK detection.  It should detect
> > traditional BLAS/LAPACK, CBLAS/CLAPACK, ATLAS, PhiPACK, and Apple's
> > compatible vector library.
> 
> Unfortunately, it reduces detection rather than expanding it.

Aside from the issues you mention, it actually does expand detection.

> The following changes need to be made:
> 
> 1. --with-gfortran should default to "no". The only things which
> should default to yes are those which most users will have and want.

I'm under the impression that most users have upgraded to GCC >= 4.x.
The reason that the option exists at all is because of autoconf-2.13
limitations.

Suggestions are welcome.

> We adopted this behaviour because, otherwise, users would fail to
> notice the warning about e.g. libpng not being found and then posted
> to the list asking "where is the PNG driver?"
> 
> Features that most users won't care about don't need this treatment. 
> It just means that the user has to go back and re-run configure with
> an extra --without-* switch.
> 
> 2. Failure to locate cblas.h and/or clapack.h must not cause a fatal
> configure error.
> 
> I don't have these files, but --with-blas and --with-lapack worked
> fine until the latest changes.

This is why I wanted people to test.  That's easily fixed.

> LOC_CHECK_INCLUDES() can take a fourth argument comprising code to be
> executed if the check fails. If no such argument is given, a fatal
> error is generated.

Okay.  That helps.  I didn't trace through all of the substitutions of
the LOC_() macros and there is almost no documentation.

> 3. --with-g77 should not be required to detect g2c.h/f2c.h or -lg2c.

Why bother detecting if there's no Fortran compiler?  Nevermind.  I see
what you're getting at.  You don't need a working Fortran compiler to
use the above.

> Again, I never needed this before.
> 
> I'm not actually compiling any Fortran code, just C code which uses a
> library written in Fortran; this doesn't require a Fortran compiler.
> 
> It may require some support files (header, library) which are normally
> installed with the Fortran compiler, but those can (and should) be
> detected as with any header or library. There's no need to check for a
> Fortran compiler unless you're actually going to be compiling Fortran
> code.

I wanted to leave the possibility open, but no, it is not specifically
needed at the present time.

> For now, I've reverted my local configure[.in] to the previous version
> to eliminate the regressions. Unless some other fix is found, I intend
> to commit the reversions.

That's a bit of a radical move for relatively minor issues, isn't it?
If you can hold out until tomorrow, I will commit fixes.


-- 
73, de Brad KB8UYR/6 <rez touchofmadness com>