[Scons-users] Symbolic links and Scons

[Marc Branchaud]

On 14-06-16 02:54 AM, Erling D. Andersen wrote:
> [This is a repost since my initial email did not make it to archive initially.]
> 
> We use scons to create so symbolic to an shared object (=.so file). Now that
> give rise to the error 
> 
>   scons: *** [bld/gram/final/default/intelc-14.0.1/dll/libmosek64.so] File exists
> 
> 
> in some cases. 
> 
> 
> Here is the diagnose behind the problem.
> 
> 
> When we rebuild the shared object then of course
> 
>   1. The shared object target is deleted
>   2. The symbolic link should be deleted.
> 
> Now if Scons happens to delete the shared object first then symbolic does
> ***NOT*** get deleted because the file the symbolic link points to does not
> exists. Now if it happens to delete symbolic link first it works fine.

We've run into similar problems with symlinks, though it hasn't been a
show-stopper for us.

SCons should treat a symlink as an independent entity, distinct from the
linked-to file.  For dependency calculations, the "contents" of a symlink
should be the value of the link (i.e. what readlink prints).

> How does scons decide when to delete symbolic links? Anyone knows where that
> decision is made in scons source code?

Unfortunately I don't know where SCons does this.

However, I suspect that messing with the way SCons treats symlinks could
confuse SCons when VariantDir() decides to duplicate files with symlinks
instead of hard links.

		M.