On Sun, Sep 7, 2014 at 9:45 AM, <[email protected]> wrote: > > Le 7 sept. 2014 à 14:53, Russel Winder <[email protected]> a écrit : > > > On Sat, 2014-09-06 at 20:31 +0200, [email protected] 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
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
