>> 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:[email protected]] 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 <[email protected]<mailto:[email protected]>> wrote: On Sun, Jul 27, 2014 at 3:02 AM, William Blevins <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> > wrote: >> >> On Sat, Jul 26, 2014 at 6:33 PM, Gary Oberbrunner >> <[email protected]<mailto:[email protected]>> >> 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 >> [email protected]<mailto:[email protected]> >> http://two.pairlist.net/mailman/listinfo/scons-dev > > > > _______________________________________________ > Scons-dev mailing list > [email protected]<mailto:[email protected]> > http://two.pairlist.net/mailman/listinfo/scons-dev > -- anatoly t. _______________________________________________ Scons-dev mailing list [email protected]<mailto:[email protected]> http://two.pairlist.net/mailman/listinfo/scons-dev
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
