[Scons-dev] Windows Path

[Gary Oberbrunner]

On Sun, Sep 7, 2014 at 9:45 AM, <alexandre.feblot at gmail.com> wrote:

>
> Le 7 sept. 2014 à 14:53, Russel Winder <russel at winder.org.uk> a écrit :
>
> > On Sat, 2014-09-06 at 20:31 +0200, alexandre.feblot at gmail.com wrote:
> >> Hi,
> >>
> >> Creation of a temporary dir containing symlinks to tools which have
> been found, and adding this dir in the SCons PATH?
> >> On windows, this can be achieved with junction points (this is pretty
> much what we do to force using the 64 bit linker during a 32 bit
> compilation due to the size of our libs/executables in debug mode).
> >
> > Indeed this works in principle for all platforms not just Windows, OSX
> > without MacPorts or HomeBrew for example.
> >
> > Doesn't windows now have proper symbolic links?
> >
> > Of course we have to deal with windows back beyond XP?
> >
> > --
> > Russel.
>
>
> Symlinks would work on unix platforms, but regarding Windows... Forget my
> suggestion, sorry:
>
> In fact, symbolic or hard links required administrator rights, so that was
> a no-go.
> Junction points didn't, but they only link directories, not files, so what
> I suggested before couldn't  be done and we in fact did something like
> env['LiNK'] = '<tmpdir>/<JunctionPoint_to_64bit_tools_dir>/link' (which is
> exactly what you want to avoid :-)
>
> And we did that in the first place because simply doing env['LINK'] =
> 'C:\Program Files\....\link' failed due to spaces in the path. But this is
> another story. Now that I think about this again, I don't even know if we
> tried just using quotes or env.File() !
>

I agree, Alexandre -- although it's clever, I think it'd be a bit _too_
clever for production use everywhere.  Too many things to go wrong.
 Simpler is better, even if it means full paths.

One thing I'm considering for the toolchain revamp is this: should a tool
be able to have a hook which modifies the environment temporarily just
before the executable runs?  That way it could temporarily add to the path.
 But I think even this is too clever; people want to be able to print out
the env and see what it's going to do, for debugging or whatever.  Plus
there's the consideration of should that same hook be run in a generator or
scanner or other places.

At the end of the day, I think we'll have to decide on a tool-by-tool basis
between (a) adding the tool's bin dir to $PATH and (b) using the tool's
full path.  I don't think there is one answer that's right for everyone.
 Here's a question for folks familiar with other similar build tools: what
do they do?  Cmake, waf, gradle, etc.?

One thing I think is definitely important for the new toolchain system is
that tools will be able to take arguments.  So at least in some cases we
could leave this decision to users; a gcc on Windows tool could have an
add_to_os_path=False arg for instance.  I'm still working on how to expose
those tool args in a reasonable way.

-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20140907/e0e74963/attachment.html>