[Scons-dev] New symlink copy support

William Blevins wblevins001 at gmail.com
Mon Jul 28 21:15:25 EDT 2014


>
> I am not sure why this is shame on them. MS uses Symilnks all the time in
> Window. As far as Intel if you install the compiler Symlinks are used on
> the system. You will see a set of links made that point to the latest
> install of the compiler. Given any modern Windows system uses NTFS and NTFS
> has native support for symlinks, not using them would just would be making
> life harder on Windows when there is no reason for it.


Point.  I've been working with legacy systems long enough I might be losing
track of the decades.


On Mon, Jul 28, 2014 at 8:55 PM, Kenny, Jason L <jason.l.kenny at intel.com>
wrote:

>  >>
>
> 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 not sure why this is shame on them. MS uses Symilnks all the time in
> Window. As far as Intel if you install the compiler Symlinks are used on
> the system. You will see a set of links made that point to the latest
> install of the compiler. Given any modern Windows system uses NTFS and NTFS
> has native support for symlinks, not using them would just would be making
> life harder on Windows when there is no reason for it.
>
>
>
> I agree that we have to be careful about forcing the use of symlinks, as
> this can be a negative.
>
>
>
> Jason
>
>
>
> *From:* Scons-dev [mailto:scons-dev-bounces at scons.org] *On Behalf Of *William
> Blevins
> *Sent:* Monday, July 28, 2014 6:40 PM
>
> *To:* SCons developer list
> *Subject:* Re: [Scons-dev] New symlink copy support
>
>
>
> > 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
>
>
>
> _______________________________________________
> 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/59ab5246/attachment-0001.html>


More information about the Scons-dev mailing list