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

Brad Douglas rez at touchofmadness.com
Wed Oct 3 14:15:18 EDT 2007


On Fri, 2007-09-28 at 16:05 +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.
> 
> 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).

FYI, I've been letting others (Markus) commit changes to 'configure'.  I
don't trust autoconf enough on x86_64 to commit it myself.  I should
really do a comparison to see if my concerns are without merit.

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

For the public record, it is being discussed offline.

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

Noted.  I've removed all "might get used in the future" code.

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

In 6.2.x, keep status quo, but I would prefer to turn it off for >= 6.3.
PostgreSQL is completely optional.


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




More information about the grass-dev mailing list