[Scons-dev] New symlink copy support

[William Deegan]

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 (wblevins001 at 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 <wblevins001 at 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 <techtonik at gmail.com> wrote:
On Mon, Jul 28, 2014 at 6:25 PM, Kenny, Jason L <jason.l.kenny at 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 at scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev


_______________________________________________  
Scons-dev mailing list  
Scons-dev at scons.org  
http://two.pairlist.net/mailman/listinfo/scons-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140729/c65ff221/attachment.html>