[CMake] LAPACK-related CMake modules

[Alan W. Irwin]

On 2008-07-21 17:27+0100 Alin M Elena wrote:

> Hi Bill,
>
>> But, there are blas and lapack libraries that can be linked from c/c++
>> right?
> Of course. Mixing fortran and C is possible. That does not make it desirable.
> If somebody wants to add support for that is my guest. I will not do it.
>> Perhaps these modules should check to see if Fortran is enabled
>> at the top, and error out if it is not.  I can fix the all module test.
> I kept the test around  check_fortran_function_exists. That should fix the
> problem.

Instead of silently failing to find BLAS and/or LAPACK if Fortran is not
enabled, there should be a message (see patch5 which I sent to you
off-list).  I am also with Bill that the message should be a FATAL_ERROR
one.

Also, for the others on list here, the "if(_LANGUAGES_ MATCHES Fortran)"
statement always fails on 2.6.0 because _LANGUAGES_ is always empty there.
So if you want to try these modules either use 2.6.1-RC11 or the CVS version
or else drop the "if(_LANGUAGES_ MATCHES Fortran)" logic in both
FindBLAS.cmake and FindLAPACK.cmake for CMake-2.6.0 since that logic is only
needed to keep C-only users from using these Fortran modules by mistake.

> I have improved a little bit the two modules.
> I have attached them here for tests and comments before adding them to the
> CVS.

I think I commented too late off list about using an environment variable to
specify the vendor (similar to the way you can choose your C compiler now
with the CC environment variable), but I hope you make that change for your
next version.

Also, your search for threads does not work for a Fortran-only project like
FreeEOS.  Here is the error message:

CMake Error: Unknown extension ".c" for file
"/home/irwin/cdburn1/interior_eos/SFHEAD/build_dir/CMakeFiles/CMakeTmp/CheckIncludeFiles.c".
  TRY_COMPILE only works for enabled languages.
  Currently enabled languages are: Fortran

I think it is important to avoid the extra C compiler dependency if possible
so I suggest for those special variants of lapack/blas that use threads, you
might be able to get away with simply specifying the appropriate linker
flags for the required thread library rather than doing a general search for
a thread library.

I have dropped the "if(_LANGUAGES_ MATCHES Fortran)" logic (since some of my
users will not have access to CMake-2.6.1 or the CVS version) and disabled
the thread logic for your two current modules for my FreeEOS project.  The
result works fine for my Debian testing platform.

Could you comment about how much the threading support is important for MKL?
I have one MKL 9 user for FreeEOS who I will ask to try out your new modules
(modified by me as above).  I will ask him to temporarily enable C and
re-enable the thread finding for his test if you think threading is
important for MKL 9.  Alternatively, if you can take care of all the special
threading needs for certain versions of lapack/blas without doing a general
search for a thread library, I would wait for your revised version before
contacting him.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________