As a side-note, Install still doesn't support symlinks which will probably change in the future.
V/R, William On Sat, Jul 26, 2014 at 8:02 PM, William Blevins <[email protected]> wrote: > 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 <[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
