> > 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.
Point. I've been working with legacy systems long enough I might be losing track of the decades. On Mon, Jul 28, 2014 at 8:55 PM, Kenny, Jason L <jason.l.ke...@intel.com> wrote: > >> > > 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-boun...@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 <techto...@gmail.com> > wrote: > > On Sun, Jul 27, 2014 at 3:02 AM, William Blevins <wblevins...@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 <techto...@gmail.com> > > wrote: > >> > >> On Sat, Jul 26, 2014 at 6:33 PM, Gary Oberbrunner < > ga...@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@scons.org > >> http://two.pairlist.net/mailman/listinfo/scons-dev > > > > > > > > _______________________________________________ > > Scons-dev mailing list > > Scons-dev@scons.org > > http://two.pairlist.net/mailman/listinfo/scons-dev > > > > > -- > anatoly t. > > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > http://two.pairlist.net/mailman/listinfo/scons-dev > > > > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > http://two.pairlist.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev