[Scons-dev] New symlink copy support

[William Blevins]

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140729/149b065e/attachment-0001.html>