[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).
> 
> There is not Fortran code in the tree (but I was keeping the option open
> as previously noted).  Change committed.

FWIW, the committed configure and configure.in scripts didn't match
(configure.in had --with-gfortran default to "no", but the actual
configure script still defaulted to "yes"). I have regenerated
configure and committed it (just in case you were wondering what the
change was).

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

Right; AC_CHECK_HEADERS is most suitable for that.

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

I wouldn't complicate configure.in with checks for something we aren't
actually using.

Given our relatively low level of manpower compared to the size of the
code base, we should be more agressive about getting rid of "dead
wood", IMHO. In the event that some old code turns out to be useful to
someone, they can always dig it out of CVS.

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

configure.in is already up to revision 1.130; a few more won't harm.

So long as it doesn't get forgotten, I can just build --without-blas
and --without-lapack for the time being (i.e. until the lack of
cblas.h and clapack.h is no longer fatal).

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

My main concern is that people won't notice that they have suddenly
stopped getting PostgreSQL support until they actually need to use it
and find that it isn't there.

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