[CMake] Auxiliary fortran link libraries?

[John Cary]

Thanks very much again for your help.  I now have enough
to fix my problem.  Some more info below that might be of
general interest.

On 7/19/10 12:43 PM, Brad King wrote:
> On 07/19/2010 11:46 AM, John R. Cary wrote:
>    
>> and I passed the correct fortran, so I also know that what is
>> here:
>>
>>    numbersix.cary$ grep IMPLICIT CMakeFiles/CMakeFortranCompiler.cmake
>>    SET(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES "gfortran")
>>    SET(CMAKE_Fortran_IMPLICIT_LINK_DIRECTORIES
>>    "/usr/local/lib/gcc/x86_64-apple-darwin10/4.5.0;/usr/local/lib")
>>
>> So can I just INCLUDE CMakeFiles/CMakeFortranCompiler.cmake and
>> then add these libraries to my target in cases where I know they
>> are correct?
>>
>> Or perhaps the include is done automatically?
>>      
> The presence of that file is undocumented but it is always included
> as part of enabling a language anyway.  The variables mentioned above
> *are* documented so you can reference them.  However, this is a
> workaround too.  If you have a C/C++ project that depends on Trilinos
> your code should not have to be aware of the Trilinos->blas->Fortran
> dependency.
>    

Thanks.  I will do this workaround for now.
> Note that if you use the *shared* libblas.so and liblapack.so then
> you do not need to list the implementation dependencies explicitly.
> Another way to view this is that when you pointed Trilinos at the
> blas and lapack libraries to use, you chose the static ones but
> did not mention their dependencies.  This is where the manual
> interference comes in.
>
>    

Got it.  I use static libs alot because I am forced to
on some of the Crays and BGPs.

> You could set TPL_LAPACK_LIBRARIES and TPL_BLAS_LIBRARIES to list
> the dependencies (by full path!).  Indeed, these variables are
> documented as
>
> "List of semi-colon separated full paths to the libraries for
>   the TPL BLAS.  This is the final variable that is used in the
>   link commands."
>
>    

Yes.  Interestingly, it seems that this is buggy, as I noted
to the trilinos team last week or so.  On my Linux box the
pointed to what was in /usr/lib64, but due to system setup
(ld.so.conf), trilinos was actually picking up the atlas libs.

Thanks again.  I see how to proceed.

John Cary