Re: [Scons-dev] Windows Path
On Sun, Sep 7, 2014 at 9:45 AM, wrote: > > Le 7 sept. 2014 à 14:53, Russel Winder a écrit : > > > On Sat, 2014-09-06 at 20:31 +0200, alexandre.feb...@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'] = '//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 Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Windows Path
Le 7 sept. 2014 à 14:53, Russel Winder a écrit : > On Sat, 2014-09-06 at 20:31 +0200, alexandre.feb...@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'] = '//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() ! Alexandre ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Windows Path
On Sat, 2014-09-06 at 20:31 +0200, alexandre.feb...@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. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Windows Path
On Sat, 2014-09-06 at 13:54 -0400, Gary Oberbrunner wrote: […] > It is the case. I think it's not right. If a tool is installed in its > preferred location, SCons should find it, on whatever OS. (This is part of > what Anatoly was mentioning before, but solving this wouldn't solve all of > that problem.) As with Python being in c:\Python34, D goes into c:\D. Of course in a proper system with packaging everything goes in the same place. Hence the ease of handling this on Linux, OSX, etc. Though I guess for OSX this only works for MacPorts and HomeBrew. Without them it is back to the Windows-like chaos. > It is tricky though, because SCons tools shouldn't muck with > env['ENV']['PATH'] too much; otherwise adding a tool may change the result > of a build. Some tools just put the whole path to the tool executable in > as the value of, say, $CC. But that of course makes the generated compile > lines look ugly. Definitely, tehre is no easy solution to this. Hence why I felt the where_is default was in conflict with the rest of SCons. > For MinGW in particular it might be dangerous to add its bin dir to > env['ENV']['PATH'] because I think MinGW puts all kinds of Unixy tools in > that bin dir, which (as William points out) would make builds less > reproducible. So Microsoft compilers are the only ones found? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Windows Path
On Sat, 2014-09-06 at 12:19 -0400, William Blevins wrote: > Even on Linux SCons doesn't use the PATH as defined by the shell. This is > intentional so that builds can be reproduced. You may need to add > additional path directories or push the shell PATH into the SCons > environment path. Absolutely. Greg was always very vocal on how any other decision was totally unacceptable. I have hacked the D tools tests to use: test.where_is(tool, Base()['PATH']) which forces where_is to use the SCons default path for the platform. This has I think fixed the recurring problem that the D tools tests were getting false positives for tools in the path. However the above is a "hideous hack", we need a better default for where_is. But I think though I have successfully made my case on this :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Windows Path
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). Regards Le 6 sept. 2014 à 19:54, Gary Oberbrunner a écrit : > > > > On Sat, Sep 6, 2014 at 12:08 PM, Russel Winder wrote: > There appears to be a fundamental problem with SCons tests on Windows, > but this just maybe due to me using Windwoes for the first time in well > over 22 years. > > I install a compiler, well two actually, MinGW and DMD, both to their > preferred installations. Both are usable from cmd.exe. However SCons > does not find either of them. This would imply that SCons is ignoring > the %PATH% at the system level. > > Is this the case, or am I missing something. > > It is the case. I think it's not right. If a tool is installed in its > preferred location, SCons should find it, on whatever OS. (This is part of > what Anatoly was mentioning before, but solving this wouldn't solve all of > that problem.) > > It is tricky though, because SCons tools shouldn't muck with > env['ENV']['PATH'] too much; otherwise adding a tool may change the result of > a build. Some tools just put the whole path to the tool executable in as the > value of, say, $CC. But that of course makes the generated compile lines > look ugly. > > For MinGW in particular it might be dangerous to add its bin dir to > env['ENV']['PATH'] because I think MinGW puts all kinds of Unixy tools in > that bin dir, which (as William points out) would make builds less > reproducible. > > -- > Gary > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Windows Path
On Sat, Sep 6, 2014 at 12:08 PM, Russel Winder wrote: > There appears to be a fundamental problem with SCons tests on Windows, > but this just maybe due to me using Windwoes for the first time in well > over 22 years. > > I install a compiler, well two actually, MinGW and DMD, both to their > preferred installations. Both are usable from cmd.exe. However SCons > does not find either of them. This would imply that SCons is ignoring > the %PATH% at the system level. > > Is this the case, or am I missing something. > It is the case. I think it's not right. If a tool is installed in its preferred location, SCons should find it, on whatever OS. (This is part of what Anatoly was mentioning before, but solving this wouldn't solve all of that problem.) It is tricky though, because SCons tools shouldn't muck with env['ENV']['PATH'] too much; otherwise adding a tool may change the result of a build. Some tools just put the whole path to the tool executable in as the value of, say, $CC. But that of course makes the generated compile lines look ugly. For MinGW in particular it might be dangerous to add its bin dir to env['ENV']['PATH'] because I think MinGW puts all kinds of Unixy tools in that bin dir, which (as William points out) would make builds less reproducible. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Windows Path
Even on Linux SCons doesn't use the PATH as defined by the shell. This is intentional so that builds can be reproduced. You may need to add additional path directories or push the shell PATH into the SCons environment path. V/R, William On Sat, Sep 6, 2014 at 12:08 PM, Russel Winder wrote: > There appears to be a fundamental problem with SCons tests on Windows, > but this just maybe due to me using Windwoes for the first time in well > over 22 years. > > I install a compiler, well two actually, MinGW and DMD, both to their > preferred installations. Both are usable from cmd.exe. However SCons > does not find either of them. This would imply that SCons is ignoring > the %PATH% at the system level. > > Is this the case, or am I missing something. > > -- > Russel. > > = > Dr Russel Winder t: +44 20 7585 2200 voip: > sip:russel.win...@ekiga.net > 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
[Scons-dev] Windows Path
There appears to be a fundamental problem with SCons tests on Windows, but this just maybe due to me using Windwoes for the first time in well over 22 years. I install a compiler, well two actually, MinGW and DMD, both to their preferred installations. Both are usable from cmd.exe. However SCons does not find either of them. This would imply that SCons is ignoring the %PATH% at the system level. Is this the case, or am I missing something. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
