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

[Brad Douglas]

On Fri, 2007-09-28 at 09:51 +0100, Glynn Clements wrote:
> 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).

There is not Fortran code in the tree (but I was keeping the option open
as previously noted).  Change committed.

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

I do need to set macros in config.h if certain headers are found, but
without fatalities if they are not.  I'll work around it.

I'll add your notes to aclocal.m4 where applicable.

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

Trying to make gfortran work with autoconf-2.13 is a kludge at best.
Maybe I should remove Fortran entirely?  I don't see much possibility
for using it in the future.

> > > 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'd still like to revert, go ahead.  I can easily recommit a
corrected version, which may be more desirable than applying fix after
fix and "polluting" the CVS history.

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

You are correct that PostgreSQL does not need to belong there anymore.

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

Simply switching the default in configure.in doesn't need to wait for
7.x.


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