[Scons-dev] New symlink copy support

[anatoly techtonik]

On Tue, Jul 29, 2014 at 2:39 AM, William Blevins <wblevins001 at 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.