[Swift-devel] could swift use return code from falkon as a success notification?

[Ben Clifford]

r2267 removes most references to $SWIFT_HOME and adds a caution on the 
remaining reference., in the docs/ documentation.

On Fri, 3 Oct 2008, Mihael Hategan wrote:

> Yes. I see that. Although the documentation does not say you should set
> it, the way it's structured seems to imply so.
> 
> I think we should correct that.
> 
> On Fri, 2008-10-03 at 10:55 -0500, Zhao Zhang wrote:
> > I think it is from swift web page some time ago.
> > 
> > zhao
> > 
> > Mihael Hategan wrote:
> > > There are legitimate cases for setting the classpath. Not so much for
> > > SWIFT_HOME.
> > >
> > > Zhao, why do you set SWIFT_HOME?
> > >
> > >
> > > On Fri, 2008-10-03 at 11:27 +0000, Ben Clifford wrote:
> > >   
> > >>> There you go. You have "." in you classpath, and you're running swift
> > >>> from ~/swift/etc which contains a bogus vdl-int.k
> > >>>       
> > >> That's hit someone before, maybe Nika when she was trying to use falkon?
> > >>
> > >>     
> > >>> 1. Swift/cog launchers using a pre-existing CLASSPATH has so far caused
> > >>> only problems and I have never heard of anybody having a legitimate use
> > >>> for this behavior (which may be because people don't complain if they
> > >>> don't have a problem). So I'm thinking of removing that. Any opinions?
> > >>>       
> > >> I was thinking very similar about SWIFT_HOME yesterday, which similarly 
> > >> appears to only have use in screwing up installations.
> > >>
> > >> CLASSPATH would have use if people started trying to do link/run time 
> > >> loading of interesting things, rather than compiling stuff into the source 
> > >> directory. But that doesn't happen.
> > >>
> > >> I think I'm happy with both of those being ignored from the calling 
> > >> environment, or at least a stern warning being given or both.
> > >>
> > >>     
> > >
> > >
> > >   
> 
>