William, Yes that is used for VariantDir’s.. There’s also an argument to such:
BuildDir(build_dir, src_dir, [duplicate]) , env.BuildDir(build_dir, src_dir, [duplicate]) Deprecated synonyms for VariantDir and env.VariantDir(). The build_dir argument becomes the variant_dir argument of VariantDir or env.VariantDir(). Note you’ll find more detail in the manpage: http://scons.org/doc/production/HTML/scons-man.html Search for VariantDir(). If you’re going to use SCons in any significant way, a thorough read of the manpage and user guide will serve you well. -Bill On July 29, 2014 at 5:06:30 PM, William Blevins (wblevins...@gmail.com) wrote: Is SCons option "--duplicate=DUPLICATE" used to control Variant copying behavior? Seems that SCons already has functionality equivalent to CCopy that could utilized for Copy. V/R, William On Tue, Jul 29, 2014 at 7:27 PM, William Blevins <wblevins...@gmail.com> wrote: I can't foresee any situation where global switch will be useful, but it may be worthy to set one. I hope our goal is to to have intelligent and fast build system, not the one creeping with options. So if we can make automatic defaults that work fast thanks to symlinks where this is supported without breaking former logic - I am all +1. I personally think a global switch would be very convenient if you don't like the default behavior. Options are fine if they are handled like "scons --debug=<items>" so the options are well categorized. I agree that a lot of base level options can be scary though. It may not break previous logic, but it may not have the desired effect. The difference is subtle, but could be even harder to troubleshoot. I do think the original effort should have been to do this in the first place. I didn't know it existed until after the changes had been discussed, reviewed, and merged. V/R, William On Tue, Jul 29, 2014 at 12:51 PM, anatoly techtonik <techto...@gmail.com> wrote: On Mon, Jul 28, 2014 at 6:25 PM, Kenny, Jason L <jason.l.ke...@intel.com> wrote: > 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. My take is that's the way to go if we are making this Copy logic implicit. If there is a fallback mechanism then there won't be any issues. > 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. I can't foresee any situation where global switch will be useful, but it may be worthy to set one. I hope our goal is to to have intelligent and fast build system, not the one creeping with options. So if we can make automatic defaults that work fast thanks to symlinks where this is supported without breaking former logic - I am all +1. _______________________________________________ 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
