[Scons-dev] New symlink copy support

[William Blevins]

>
> > 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 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.


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.

V/R,
William


On Mon, Jul 28, 2014 at 3:01 AM, anatoly techtonik <techtonik at gmail.com>
wrote:

> On Sun, Jul 27, 2014 at 3:02 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.
>
> > 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 <techtonik at gmail.com>
> > wrote:
> >>
> >> On Sat, Jul 26, 2014 at 6:33 PM, Gary Oberbrunner <
> garyo at 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 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
> >
>
>
>
> --
> anatoly t.
> _______________________________________________
> 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/20140728/1e8947a6/attachment-0001.html>