[vsipl++] [patch] Install cml_kernels.so

[Brooks Moses]

Jules Bergmann wrote, at 9/19/2008 4:11 AM:
>> There's what may be a minor problem with this bit:
>>> +# NOTE: Installing cml_kernels.so is a work-around for SDK 3.0 ALF, which
>>> +#       only accepts 1 directory in ALF_LIBRARY_PATH.  libs/cml_kernels.so
>>> +#       is a link created by configure.
>>>  install-core:: lib/svpp_kernels.so
>>>  	$(INSTALL) -d $(DESTDIR)$(libdir)
>>>  	$(INSTALL_PROGRAM) lib/svpp_kernels.so \
>>>            $(DESTDIR)$(libdir)/svpp_kernels.so
>>> +	$(INSTALL_PROGRAM) lib/cml_kernels.so \
>>> +          $(DESTDIR)$(libdir)/cml_kernels.so
>> The lib/cml_kernels.so file is created with this line:
>>
>>     ln -sf $with_cml_prefix/$cml_libdir_found/cml_kernels.so lib
>>
>> A bit of experimenting indicates that install will, when presented with
>> trying to install a symlink to file $FOO over top of file $FOO, throw an
>> error about them being the same file and emit a nonzero return value.
>> This will stop the "make install" process.
> 
> Interesting.  So the bug occurs installing the library a second time?

No; it occurs if we're installing VSIPL++ into the same directory that
CML is installed into already, and if we give VSIPL++ that install
directory as the location to find cml_kernels.so.  In other words, it
occurs when --with-cml-prefix and --with-libdir point to the same place,
such that the pre-existing file is the target of the cml_kernels.so
symlink in the build directory that install is trying to use as a source
to install on top of it.

If we're installing the library a second time, the existing behavior is
that install copies the "new" file on top of the "old" file, and there
is no problem.

>> The attached patch should fix this; okay to commit?
> 
> The behavior isn't intuitive.  When installing a new VSIPL++ over an 
> existing one, one would expect the old files to be overwritten. 
> However, the patch appears to preserve the older file.

It does -- because, in the use case I was thinking of, the "older" file
is the target of the symlink that is the new file, and so if I instead
delete the "older" file, the new file that I'm trying to recreate it
from suddenly goes away too.

Perhaps a better solution is to replace the symlink with a copy when the
$builddir/lib/cml_kernels.so file is created?  That way, install can
always smash any existing cml_kernels.so file with the copy, even if
it's the one that it got the copy from.

- Brooks