[vsipl++] [patch] Misc bits; prep for updating svn:externals

[Jules Bergmann]

Stefan Seefeld wrote:
> Jules Bergmann wrote:
> 
>> Index: configure.ac
>> ===================================================================
>> --- configure.ac	(revision 171903)
>> +++ configure.ac	(working copy)
> 
>> @@ -1976,12 +1985,12 @@
>>      echo "HOST: $host  BUILD: $build"
>>      if test "$host" != "$build"; then
>>        # Can't cross-compile builtin atlas
>> -      lapack_packages="atlas generic1 generic2 simple-builtin"
>> +      lapack_packages="atlas generic_wo_blas generic_with_blas generic_v3_wo_blas generic_v3_with_blas simple-builtin"
>>      else
>> -      lapack_packages="atlas generic1 generic2 builtin"
>> +      lapack_packages="atlas generic_wo_blas generic_with_blas generic_v3_wo_blas generic_v3_with_blas builtin"
>>      fi
>>    elif test "$with_lapack" == "generic"; then
>> -    lapack_packages="generic1 generic2"
>> +    lapack_packages="generic_wo_blas generic_with_blas generic_v3_wo_blas generic_v3_with_blas"
>>    elif test "$with_lapack" == "simple-builtin"; then
>>      lapack_packages="simple-builtin";
>>    else
> 
> Jules,
> 
> some weeks ago we were discussing the possibility to allow users to pass
> a comma-separated list of backends to --with-lapack, obsoleting some of
> the (compound) options above. Do you still think we may do that ?

Yes, definitely.  This was meant to be a step in that direction 
(replacing cryptic 'generic1' with less-cryptic 'generic_wo_blas', etc).

I would like to allow users to specify a comma separated list of 
backends, but I would like to keep some of the current smarts, such as 
avoiding ATLAS when cross-compiling (since ATLAS can't be cross 
compiled) and searching for the different permutations of lapack 
({with/without BLAS} x {lapack.a / lapack-3.a}).

I don't know why there is so much variation in lapack/atlas/mkl.  What I 
would *really* like is for those libraries to provide us with a 
pkg-config file :)

> (Also, some documentation concerning the meaning of the various options
>  may help to illustrate the parameter space. I'd offer to write that, but
> each time I spend more than two minutes thinking about it I'm getting
> confused again. :-) )

Ok.  Let's start with the documentation embedded in configure.   Right 
now it documents the following lapack choices ('--with-lapack=PKG'):

   mkl -- Intel Math Kernel Library
   acml -- AMD Core Math Library
   atlas -- System ATLAS/LAPACK installation
   generic -- system generic LAPACK installation
   builtin -- Sourcery VSIPL++'s builtin ATLAS/C-LAPACK
   fortran-builtin -- Sourcery VSIPL++'s builtin ATLAS/LAPACK
   simple-builtin -- Lapack that doesn't require atlas.

I think it is fairly descriptive.  We could clarify the builtin 
variants, perhaps:

   builtin -- Sourcery VSIPL++'s builtin ATLAS/C-LAPACK.  Requires
              only C compiler.  Cannot be cross-compiled.

   fortran-builtin -- Sourcery VSIPL++'s builtin ATLAS/C-LAPACK.
              Requires C and FORTRAN compilers.  Cannot be
              cross-compiled.   Typically has better performance than
              'builtin'.

   simple-builtin -- Sourcery VSIPL++'s builtin C-LAPACK.  Does not
              use ATLAS so performance is lower than 'builtin' and
	     'fortran-builtin'.  However, only requires C compiler
              and can be cross-compiled.

Although I'm not sure we need that level of detail in configure itself. 
  It could certainly go into the quickstart though.

What do you think?  What additional clarification would be useful?

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705