[Scons-dev] New symlink copy support
William Blevins
wblevins001 at gmail.com
Sat Jul 26 20:02:12 EDT 2014
I think it is reasonable for SCons to support symlinks on systems that
support symlinks.
I develop primarily on UNIX-based systems and I don't use symlinks often
with SCons because SCons didn't support symlink copy. Example: versioned
shared libraries. For me to do libA.so, libA.so.1, and libA.so.1.0.0, I
actually had to make 3 copies of the same file before which isn't practical
(or acceptable behavior really).
If we have a lot of complaints, then we could can the default. I don't see
this happening. I think there are fair more people that want this behavior
which didn't exist, than those who will be opposed to it.
V/R,
William
On Sat, Jul 26, 2014 at 6:36 PM, anatoly techtonik <techtonik at gmail.com>
wrote:
> On Sat, Jul 26, 2014 at 6:33 PM, Gary Oberbrunner <garyo at oberbrunner.com>
> wrote:
> > What's wrong with copying symlinks if that's what the user wants?
>
> Nothing wrong if user know that he wants to copy symlinks. But I am sure
> most users just want to copy ordinary files. So if somebody wants symlink
> copy, it should be stated explicitly and not be a default behavior.
>
> > I have some pure python Windows symlink code lying around somewhere too.
> > Works fine on NFL.
>
> os.symlink() is not that code and that is the code that unconditionally
> invoked
> on Copy if I am not mistaken.
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> http://two.pairlist.net/mailman/listinfo/scons-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140726/23b89fd1/attachment.html>
More information about the Scons-dev
mailing list