Re: [Scons-dev] Multi-platform development
On Sun, Sep 7, 2014 at 9:50 AM, Russel Winder wrote: > Because I have Python 3 installed as default I have a symbolic link > python2 to 2.7: > > python2 runtest.py test/D > > leads to an error in shutil.copytree at QMTest/TestCmd.py line 1275. > > shutil.py line 208 is raising an exception operation not permitted > on /private/tmp/testcmd.98136.Tj_v70/./p/submodule2.d > This could simply be how you've configured samba on the linux side. There are various security options; check e.g. https://www.samba.org/samba/docs/using_samba/ch09.html. Also try using PRESERVE=1 and look at the permissions in /private/tmp/testcmd. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
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
[Scons-dev] Base SCons path for OSX
I wonder if it might be acceptable to amend the darwin path a bit. From the source of SCons/Platform/darwin.py it seems that /etc/paths and /etc/paths.d/* are all processed and then MacPorts and Fink paths added. I think Fink is dead but I guess we can leave it for now. However I think HomeBrew should be added to the list. On the other hand adding MacPorts and Fink makes things very variable, but then of course /etc/paths and /etc/path.d/* cannot be relied on anyway :-) -- 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] Multi-platform development
On Sat, 2014-09-06 at 06:15 -0400, Gary Oberbrunner wrote: > Since I know OSX requires the root filesystem to be HFS+, I guess you're > trying to mount your SCons source tree remotely via SMB/CIFS and run the > test suite from there? I'd expect that to work. What fails? Could it be > caused by your SAMBA config on Linux? I connect to a server using Finder|Go|Connect to server…, which works fine. (Yes it is a samba server on the grounds that Apple decided to stop people using NFS :-( I then cd to the directory on the server via the path /Volumes/home/users/russel/… Because I have Python 3 installed as default I have a symbolic link python2 to 2.7: python2 runtest.py test/D leads to an error in shutil.copytree at QMTest/TestCmd.py line 1275. shutil.py line 208 is raising an exception operation not permitted on /private/tmp/testcmd.98136.Tj_v70/./p/submodule2.d So the problem is in the Python distribution, which probably means it will take years to not be fixed. > > Has anyone found a way of working with a single filestore and two > > platforms so as to develop for multiple platforms at the same time? > > > > If you just copy the SCons source tree onto the HFS+ drive does it work > then? The OSX machine has an exact replica on the filestore I have on all my machines and yes, it all works fine on the local disc. -- 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
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] Time for a show down…
On Sat, 2014-09-06 at 06:27 -0400, Gary Oberbrunner wrote: > On Sat, Sep 6, 2014 at 6:16 AM, Russel Winder wrote: > > > TestSCons.TestSCons.where_is searches the user's path for an executable. > > When running tests SCons does not use the users path, just the default > > system path, to search for executables. where_is is therefore either > > broken or useless. > > > > I hear you. Let's say it is broken. What's the fix? Don't use $PATH by > default? Having "slept on it", yes I think this is what I mean. where_is is a fine method per se, it just has the wrong default behaviour: default should be whatever SCons default path is and parameters should be given to change it. > Some tests want to deliberately look in $PATH and set up the test > accordingly; > maybe the simple fix is just to not use os.environ['PATH'] when the > passed-in > optional path arg is None. Any test that really wants that would have to > explicitly pass os.environ['PATH']. I wonder how many tests that would > break. We need three possibilities: a. SCons default, b. Users PATH, c. arbitrary path. Currently None means Users PATH and the alternative is arbitrary path. I need to think a bit more about the possibilities of parameters to make this work best. Others may already have good solutions. -- 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
