[vsipl++] [patch] autodetect CML libdir

Stefan Seefeld stefan at codesourcery.com
Tue Aug 26 03:31:41 UTC 2008


Jules Bergmann wrote:
> This detects if the libcml.a is in $cml_prefix/lib or $cml_prefix/lib64.
> 
> I'm manually packaging up an eval CML with the following layout:
> 
>     cml/include    headers (shared)
>      cml/lib        libraries (32-bit)
>     cml/lib64    libraries (64-bit)

I take it 'cml' here stands for the installation prefix, e.g. '/usr'. 
Correct ?

> this patch lets VSIPL++ take a single cml prefix and find the right 
> library.
> 
> Ok to apply?

The patch looks good. One little nitpick:

> +    for trylibdir in $libdirs; do
> +      AC_MSG_CHECKING([for CML libdir: $with_cml_prefix/$trylibdir])
> +
> +      CPPFLAGS="$orig_CPPFLAGS -I$with_cml_prefix/include"
> +      LDFLAGS="$orig_LDFLAGS -L$with_cml_prefix/$trylibdir"
> +      CPP_SPU_FLAGS="$orig_CPP_SPU_FLAGS -I$with_cml_prefix/include"
> +      LD_SPU_FLAGS="$orig_LD_SPU_FLAGS -L$with_cml_prefix/$trylibdir"

AFAICT, the trylibdir loop only affects LDFLAGS and LD_SPU_FLAGS, so you 
may keep the definition of CPPFLAGS and CPP_SPU_FLAGS as they were.

> +    # ALF_LIBRARY_PATH (ALF 3.0) only supports a single path.
> +    # Create link to CML kernels from VSIPL++ directory.
> +    # This allows in-tree development.  It will not be copied
> +    # on installation.
> +    mkdir -p lib
> +    ln -sf $with_cml_prefix/$cml_libdir_found/cml_kernels.so lib

Let's not forget to remove that, eventually, since:

1) $with_cml_prefix may be empty (for example if CML can be found in a 
default location) and
2) ALF 3.1 will no longer need that.

Eventually we'll also have to come back to the point of whether and how 
to define ALF_LIBRARY_PATH. My personal preference would be to allow 
SV++ and CML to accumulate search paths and then set them via 
alf_init(). However, if I remember correctly, ALF_LIBRARY_PATH would, if 
set, simply override that, instead of complement it. Thus users are 
required to carry the full set of search paths around. Oh well...


Thanks,
		Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718



More information about the vsipl++ mailing list