Anatoly, What is your take on the CCopy behavior in Parts. I believe this addresses the issue you are concern over. The logic be default is to do a hard-soft-copy which is to say make a hard link, else symlink, else full copy. I personally wanted to default to symlink-hard-copy. But honestly to many windows system have the wrong permission set by default so making symlinks would always fail. And there is some odd behavior on linux when the build makes first call symlinks that are mixed with "copied" symlinks. The code allow the user to explicitly set the "copy" logic for the whole build and allow a given copy to be set to have exact semantics the user wants independent of what the whole build is set to.
Jason -----Original Message----- From: Scons-dev [mailto:[email protected]] On Behalf Of anatoly techtonik Sent: Saturday, July 26, 2014 5:37 PM To: SCons developer list Subject: Re: [Scons-dev] New symlink copy support 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
