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