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

[Glynn Clements]

Brad Douglas wrote:

> > 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.

Regardless of which GCC version people are using (I'm using 3.4.6),
there's no need for either --with-g77 or --with-gfortran to be enabled
by default.

And unless there's some Fortran code still in GRASS (I can't see any),
I don't see any need for those options to exist. The AC_CHECK_PROGS
for g77/f77 was commented out when we no longer included any Fortran
code. 5.3 has some, but 6.x doesn't (AFAICT).

> > 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.

If you only need to set a HAVE_FOO_H macro in config.h, use
AC_CHECK_HEADERS instead.

LOC_CHECK_INCLUDES is designed for the situation where a header is
mandatory. The fourth argument is designed so that you can nest checks
for alternate headers (see the FFTW and GLw checks for examples), with
a fatal error if none of the alternatives are found.

> > 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.

Right. If we do ever find a use for a Fortran compiler, the checks
should be orthogonal to those required to use Fortran-based libraries
(e.g. LAPACK).

> > 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?

Well, from my perspective, the changes were entirely negative. 
Compiling with BLAS/LAPACK support was impossible regardless of
configure options, and even without --with-{blas,lapack}, configure
would simply fail if you don't have a Fortran compiler (many users
probably don't) and you didn't specifically use --without-gfortran.

Given the relative complexity of the tests, it looked like it would
have been safer to just revert everything until a second attempt was
made (you can always recover the first attempt from CVS).

> If you can hold out until tomorrow, I will commit fixes.

I can wait that long. The problems with the --with-{blas,lapack} case
aren't critical, but eliminating the need to use --without-gfortran
needs to be done sooner rather than later. Running configure with no
arguments should normally work for anyone who has the "standard"
dependencies (i.e. the mandatory dependencies plus JPEG, TIFF, PNG,
Tcl/Tk, PostgreSQL, OpenGL and FFTW).

[Actually, I'm not sure that PostgreSQL really belongs on that list. 
When we adopted a policy of generating fatal errors if important
dependencies were missing, PostgreSQL was the only supported database,
and it resulted in a bunch of additional pg.* modules as well as
adding PostgreSQL support to NVIZ.

Now that other databases can be used, and the option only affects
compilation of the actual database driver, it could probably be turned
off by default. OTOH, maybe that should wait for 7.x.]

-- 
Glynn Clements <glynn at gclements.plus.com>