[Scons-dev] New symlink copy support

[Kenny, Jason L]

>>
If someone is creating symlinks for code intended to be placed in a shared directory with a Windows O/S, shame on them? Does this happen in software you maintain or is this hypothetical?
>>

I am not sure why this is shame on them. MS uses Symilnks all the time in Window. As far as Intel if you install the compiler Symlinks are used on the system. You will see a set of links made that point to the latest install of the compiler. Given any modern Windows system uses NTFS and NTFS has native support for symlinks, not using them would just would be making life harder on Windows when there is no reason for it.

I agree that we have to be careful about forcing the use of symlinks, as this can be a negative.

Jason

From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of William Blevins
Sent: Monday, July 28, 2014 6:40 PM
To: SCons developer list
Subject: Re: [Scons-dev] New symlink copy support

> I think it is reasonable for SCons to support symlinks on systems that
> support symlinks.
It is not the matter of supporting, it is the matter of using them by default.
You need to check FS support - not operating systems support to make
it work without pain by default. There are many cases where people use
virtual machines to build stuff on different systems and source directory
often gets shared with network protocol that doesn't support symlinking
even if os supports it.

If someone is creating symlinks for code intended to be placed in a shared directory with a Windows O/S, shame on them? Does this happen in software you maintain or is this hypothetical?

> 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.
I am afraid the complain would be for SConstruct authors, not for SCons.

Obviously.  I think we all eat our own dog food? I imagine this will affect few developers adversely.  This adds new capability for symlinks which matches the Python API way of handling symlinks.

V/R,
William

On Mon, Jul 28, 2014 at 3:01 AM, anatoly techtonik <techtonik at gmail.com<mailto:techtonik at gmail.com>> wrote:
On Sun, Jul 27, 2014 at 3:02 AM, William Blevins <wblevins001 at gmail.com<mailto:wblevins001 at gmail.com>> wrote:
> I think it is reasonable for SCons to support symlinks on systems that
> support symlinks.
It is not the matter of supporting, it is the matter of using them by default.
You need to check FS support - not operating systems support to make
it work without pain by default. There are many cases where people use
virtual machines to build stuff on different systems and source directory
often gets shared with network protocol that doesn't support symlinking
even if os supports it.

> 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.
I am afraid the complain would be for SConstruct authors, not for SCons.

> On Sat, Jul 26, 2014 at 6:36 PM, anatoly techtonik <techtonik at gmail.com<mailto:techtonik at gmail.com>>
> wrote:
>>
>> On Sat, Jul 26, 2014 at 6:33 PM, Gary Oberbrunner <garyo at oberbrunner.com<mailto: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<mailto:Scons-dev at scons.org>
>> http://two.pairlist.net/mailman/listinfo/scons-dev
>
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org<mailto:Scons-dev at scons.org>
> http://two.pairlist.net/mailman/listinfo/scons-dev
>


--
anatoly t.
_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org<mailto: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/20140729/735bd4a4/attachment.html>