Re: [Scons-dev] New symlink copy support
On Thu, Jul 31, 2014 at 2:27 AM, William Blevins wblevins...@gmail.com wrote: I see, I missed this fact from the commit. That makes sense, but documentation needs to be simplified IMO. https://bitbucket.org/scons/scons/commits/2e225b46b2ad10230ae0a11090a7a26101866989 Because I read symbolic link copying behavior in a wrong way. Provide a suggestion? I can barely read my own mind much less anyone else's :) What about this? +para +The Copy; factory supports copying symbolic links. This behavior can be controlled by an optional third argument. +/para + +para +Symbolic link shallow copied a new symbolic link: +/para + +para +literalCommand(LinkIn, LinkOut1, Copy($TARGET, $SOURCE[, True]))/literal +/para + +para +Symbolic link target copied as a file or directory: +/para + +para +literalCommand(LinkIn, FileOrDirectoryOut, Copy($TARGET, $SOURCE, False))/literal +/para =) I'd say this: para Since SCons 2.3.x Copy has symcopy keyword argument that controls how symlinks are copied. If set to True, symlinks will be copied as links, if False, SCons will copy file pointed by symlink. /para Positional arguments are bad, because from this: Copy($TARGET, $SOURCE, False) I can't say what False stands for. My first idea is dry-run. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] New symlink copy support
I see, I missed this fact from the commit. That makes sense,
but documentation needs to be simplified IMO.
https://bitbucket.org/scons/scons/commits/2e225b46b2ad10230ae0a11090a7a26101866989
Because I read symbolic link copying behavior in a wrong way.
Provide a suggestion? I can barely read my own mind much less anyone
else's :)
What about this?
+para
+The Copy; factory supports copying symbolic links. This behavior can
be controlled by an optional third argument.
+/para
+
+para
+Symbolic link shallow copied a new symbolic link:
+/para
+
+para
+literalCommand(LinkIn, LinkOut1, Copy($TARGET, $SOURCE[,
True]))/literal
+/para
+
+para
+Symbolic link target copied as a file or directory:
+/para
+
+para
+literalCommand(LinkIn, FileOrDirectoryOut, Copy($TARGET,
$SOURCE, False))/literal
+/para
V/R,
William
On Wed, Jul 30, 2014 at 2:48 AM, anatoly techtonik techto...@gmail.com
wrote:
On Wed, Jul 30, 2014 at 3:43 AM, William Blevins wblevins...@gmail.com
wrote:
2. Get Mercurial and run tests in VM
hg clone http://selenic.com/hg
cd hg/contrib/vagrant
vagrant up
vagrant ssh -c ./run-tests.sh
Vagrant mounts current folder as /vagrant inside VM, so when I cd to
this
folder and try to create symlink, I get a nasty error:
vagrant ssh
$ cd /vagrant
$ ln config.yml config.yml2
ln: failed to create hard link `config.yml2' = `config.yml':
Operation not permitted
$ ln -s config.yml config.yml2
ln: failed to create symbolic link `config.yml2': Protocol error
$ python -c import os; os.symlink('config.yml', 'config.yml2')
Traceback (most recent call last):
File string, line 1, in module
OSError: [Errno 71] Protocol error
I've never used vagrant before, but it was fairly intuitive with your
example.
1. run-tests.sh is still executing after 30min+ and there are some
errors,
but nothing I can see related to symlinks.
2. I was able to create symlinks inside the /vagrant directory
Sorry if I was not clear. This was just to demonstrate the modern
development setup with Vagrant. The type of file system mounted
as /vagrant is your host FS. In my case it is Windows, so I get
this error.
Based on this example, I don't think your use case makes sense. In order
for the SCons Copy code to fail on os.symlink, Copy must be attempting
to
copy a symlink:
ls -l
lrwx-- item - item.txt
-rwx-- item.txt
cat SConstruct
Copy( 'item', 'item_link', True ) # default is True anyway
Copy( 'item', 'item_file', False ) # default is True anyway
scons
Copy( item, item_link )
Copy( item, item_file )
ls -l
lrwx-- item - item.txt
-rwx-- item.txt
lrwx-- item_link - item.txt
-rwx-- item_file
echo item.txt item_file inode count is 1
Copy does not try to create a symlink from a real file:
I see, I missed this fact from the commit. That makes sense,
but documentation needs to be simplified IMO.
https://bitbucket.org/scons/scons/commits/2e225b46b2ad10230ae0a11090a7a26101866989
Because I read symbolic link copying behavior in a wrong way.
Maybe it was just a bad example? You could still have this issue if you
are
copying a symlink from a filesystem that supports it to one that doesn't.
Also in Windows you can not create link from one drive to other even
if FS supports it.
___
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
Re: [Scons-dev] New symlink copy support
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
Re: [Scons-dev] New symlink copy support
On Tue, Jul 29, 2014 at 2:39 AM, William Blevins wblevins...@gmail.com wrote:
I think it is reasonable for SCons to support symlinks on systems that
support symlinks.
It is not the matter of supporting, it is the matter of using them by
default.
You need to check FS support - not operating systems support to make
it work without pain by default. There are many cases where people use
virtual machines to build stuff on different systems and source directory
often gets shared with network protocol that doesn't support symlinking
even if os supports it.
If someone is creating symlinks for code intended to be placed in a shared
directory with a Windows O/S, shame on them? Does this happen in software
you maintain or is this hypothetical?
I am taking about directories shared with Virtual Machines. I don't have
example with SCons at the moment, but these are two real world examples
wit Vagrant for you to try. It won't take a lot of time.
1. Get your own instance of http://bugs.python.org/ for hacking
https://bitbucket.org/techtonik/pydotorg-bpo
2. Get Mercurial and run tests in VM
hg clone http://selenic.com/hg
cd hg/contrib/vagrant
vagrant up
vagrant ssh -c ./run-tests.sh
Vagrant mounts current folder as /vagrant inside VM, so when I cd to this
folder and try to create symlink, I get a nasty error:
vagrant ssh
$ cd /vagrant
$ ln config.yml config.yml2
ln: failed to create hard link `config.yml2' = `config.yml':
Operation not permitted
$ ln -s config.yml config.yml2
ln: failed to create symbolic link `config.yml2': Protocol error
$ python -c import os; os.symlink('config.yml', 'config.yml2')
Traceback (most recent call last):
File string, line 1, in module
OSError: [Errno 71] Protocol error
I am afraid the complain would be for SConstruct authors, not for SCons.
Obviously. I think we all eat our own dog food? I imagine this will affect
few developers adversely. This adds new capability for symlinks which
matches the Python API way of handling symlinks.
Thinking about Python API in a positive way is a trap. Knowing the pitfalls
is a path to salvation. If our CCopy approach works, we may propose it for
inclusion.
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] New symlink copy support
So your suggestion is that I update the license file with Scons Foundation? Jason -Original Message- From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of anatoly techtonik Sent: Tuesday, July 29, 2014 12:21 PM To: SCons developer list Subject: Re: [Scons-dev] New symlink copy support On Tue, Jul 29, 2014 at 4:02 AM, Kenny, Jason L jason.l.ke...@intel.com wrote: Ideally that is the hope I have.. CCopy should be used as the backbone of all copied in Parts and I hope in SCons. Everything in Parts is done so it could be added to SCons. The license is MIT under Intel, but it is assumed that SCons will own all this code as it moves stuff over. Intel has no interest in controlling a build system. As long as license is MIT, there is no need to transfer copyright. Just add the appropriate line to LICENSE file. In fact, I prefer this way of doing things, like in Twisted. https://twistedmatrix.com/trac/browser/trunk/LICENSE Then at the top of each file we just reference the LICENSE. ___ 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
Re: [Scons-dev] New symlink copy support
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
Re: [Scons-dev] New symlink copy support
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
Re: [Scons-dev] New symlink copy support
2. Get Mercurial and run tests in VM
hg clone http://selenic.com/hg
cd hg/contrib/vagrant
vagrant up
vagrant ssh -c ./run-tests.sh
Vagrant mounts current folder as /vagrant inside VM, so when I cd to this
folder and try to create symlink, I get a nasty error:
vagrant ssh
$ cd /vagrant
$ ln config.yml config.yml2
ln: failed to create hard link `config.yml2' = `config.yml':
Operation not permitted
$ ln -s config.yml config.yml2
ln: failed to create symbolic link `config.yml2': Protocol error
$ python -c import os; os.symlink('config.yml', 'config.yml2')
Traceback (most recent call last):
File string, line 1, in module
OSError: [Errno 71] Protocol error
I've never used vagrant before, but it was fairly intuitive with your
example.
1. run-tests.sh is still executing after 30min+ and there are some errors,
but nothing I can see related to symlinks.
2. I was able to create symlinks inside the /vagrant directory
Based on this example, I don't think your use case makes sense. In order
for the SCons Copy code to fail on os.symlink, Copy must be attempting to
copy a symlink:
ls -l
lrwx-- item - item.txt
-rwx-- item.txt
cat SConstruct
Copy( 'item', 'item_link', True ) # default is True anyway
Copy( 'item', 'item_file', False ) # default is True anyway
scons
Copy( item, item_link )
Copy( item, item_file )
ls -l
lrwx-- item - item.txt
-rwx-- item.txt
lrwx-- item_link - item.txt
-rwx-- item_file
echo item.txt item_file inode count is 1
Copy does not try to create a symlink from a real file:
ls -l
-rwx-- item.txt
cat SConstruct
Copy( 'item.txt', 'item_copy', True ) # default is True anyway
scons
Copy( item.txt, item_copy )
ls -l
-rwx-- item.txt
-rwx-- item_copy
echo item.txt item_copy inode count is 1
Since the filesystem in the example does not support symlinks (I assume),
then SCons will not be trying to copy a symlink anyway.
Maybe it was just a bad example? You could still have this issue if you are
copying a symlink from a filesystem that supports it to one that doesn't.
V/R,
William
On Tue, Jul 29, 2014 at 1:13 PM, anatoly techtonik techto...@gmail.com
wrote:
On Tue, Jul 29, 2014 at 2:39 AM, William Blevins wblevins...@gmail.com
wrote:
I think it is reasonable for SCons to support symlinks on systems that
support symlinks.
It is not the matter of supporting, it is the matter of using them by
default.
You need to check FS support - not operating systems support to make
it work without pain by default. There are many cases where people use
virtual machines to build stuff on different systems and source
directory
often gets shared with network protocol that doesn't support symlinking
even if os supports it.
If someone is creating symlinks for code intended to be placed in a
shared
directory with a Windows O/S, shame on them? Does this happen in software
you maintain or is this hypothetical?
I am taking about directories shared with Virtual Machines. I don't have
example with SCons at the moment, but these are two real world examples
wit Vagrant for you to try. It won't take a lot of time.
1. Get your own instance of http://bugs.python.org/ for hacking
https://bitbucket.org/techtonik/pydotorg-bpo
2. Get Mercurial and run tests in VM
hg clone http://selenic.com/hg
cd hg/contrib/vagrant
vagrant up
vagrant ssh -c ./run-tests.sh
Vagrant mounts current folder as /vagrant inside VM, so when I cd to this
folder and try to create symlink, I get a nasty error:
vagrant ssh
$ cd /vagrant
$ ln config.yml config.yml2
ln: failed to create hard link `config.yml2' = `config.yml':
Operation not permitted
$ ln -s config.yml config.yml2
ln: failed to create symbolic link `config.yml2': Protocol error
$ python -c import os; os.symlink('config.yml', 'config.yml2')
Traceback (most recent call last):
File string, line 1, in module
OSError: [Errno 71] Protocol error
I am afraid the complain would be for SConstruct authors, not for SCons.
Obviously. I think we all eat our own dog food? I imagine this will
affect
few developers adversely. This adds new capability for symlinks which
matches the Python API way of handling symlinks.
Thinking about Python API in a positive way is a trap. Knowing the pitfalls
is a path to salvation. If our CCopy approach works, we may propose it for
inclusion.
___
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
Re: [Scons-dev] New symlink copy support
On Sun, Jul 27, 2014 at 3:02 AM, William Blevins wblevins...@gmail.com wrote: I think it is reasonable for SCons to support symlinks on systems that support symlinks. It is not the matter of supporting, it is the matter of using them by default. You need to check FS support - not operating systems support to make it work without pain by default. There are many cases where people use virtual machines to build stuff on different systems and source directory often gets shared with network protocol that doesn't support symlinking even if os supports it. 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. I am afraid the complain would be for SConstruct authors, not for SCons. On Sat, Jul 26, 2014 at 6:36 PM, anatoly techtonik techto...@gmail.com wrote: On Sat, Jul 26, 2014 at 6:33 PM, Gary Oberbrunner ga...@oberbrunner.com 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 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 -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] New symlink copy support
I agree. In Parts we added code to allow Symlinks to work as a first class object ( ie a node) In Scons. It seems to work just fine. As long as some simple rules are followed it we have not had issues on windows and or linux/mac at this point. Jason From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary Oberbrunner Sent: Saturday, July 26, 2014 10:33 AM To: SCons Dev List Subject: Re: [Scons-dev] New symlink copy support What's wrong with copying symlinks if that's what the user wants? I have some pure python Windows symlink code lying around somewhere too. Works fine on NFL. -- Gary Oberbrunner (sent from my Android) On Jul 26, 2014 10:14 AM, anatoly techtonik techto...@gmail.commailto:techto...@gmail.com wrote: Is it true that Copy now tries to copy symlinks by default? Symlinks is a can of worms. I'd avoid using them unless explicitly enables at all costs. 1. os.symlink is documented as unix only https://docs.python.org/2/library/os.html#os.symlink 2. even if os.symlink is present, it may fail (especially in shared folders mounted in VM) https://mail.python.org/pipermail/python-ideas/2014-July/028386.html -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.orgmailto: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
Re: [Scons-dev] New symlink copy support
Yes, that was how the feature request was written and that is how it was reviewed. I think that Install should work that way too in order to natively support versioned shared libraries in a rational manner. I don't have any tests for copying from unix to windows in those cases. I imagine the default action would fail just like a cp from the commandline would fail. V/R, William On Sat, Jul 26, 2014 at 4:14 AM, anatoly techtonik techto...@gmail.com wrote: Is it true that Copy now tries to copy symlinks by default? Symlinks is a can of worms. I'd avoid using them unless explicitly enables at all costs. 1. os.symlink is documented as unix only https://docs.python.org/2/library/os.html#os.symlink 2. even if os.symlink is present, it may fail (especially in shared folders mounted in VM) https://mail.python.org/pipermail/python-ideas/2014-July/028386.html -- anatoly t. ___ 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
Re: [Scons-dev] New symlink copy support
What's wrong with copying symlinks if that's what the user wants? I have some pure python Windows symlink code lying around somewhere too. Works fine on NFL. -- Gary Oberbrunner (sent from my Android) On Jul 26, 2014 10:14 AM, anatoly techtonik techto...@gmail.com wrote: Is it true that Copy now tries to copy symlinks by default? Symlinks is a can of worms. I'd avoid using them unless explicitly enables at all costs. 1. os.symlink is documented as unix only https://docs.python.org/2/library/os.html#os.symlink 2. even if os.symlink is present, it may fail (especially in shared folders mounted in VM) https://mail.python.org/pipermail/python-ideas/2014-July/028386.html -- anatoly t. ___ 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
Re: [Scons-dev] New symlink copy support
On Sat, Jul 26, 2014 at 6:33 PM, Gary Oberbrunner ga...@oberbrunner.com 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 Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] New symlink copy support
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 wblevins...@gmail.com 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 techto...@gmail.com wrote: On Sat, Jul 26, 2014 at 6:33 PM, Gary Oberbrunner ga...@oberbrunner.com 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 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
