Re: [Scons-dev] Testing non-core tools

2013-07-27 Thread Russel Winder
On Fri, 2013-07-26 at 21:36 +0200, Dirk Bächle wrote: […] > If you call the runtest.py for external tests, you have to specify the > "-e" option as well. OK the -e has helped. Now I am back with: 1/1 (100.00%) /usr/bin/python -tt test/sconstest-issue_1.py scons returned 2 STDOUT

Re: [Scons-dev] Testing non-core tools

2013-07-27 Thread Dirk Bächle
Russel, On 27.07.2013 11:45, Russel Winder wrote: On Fri, 2013-07-26 at 21:36 +0200, Dirk Bächle wrote: […] If you call the runtest.py for external tests, you have to specify the "-e" option as well. OK the -e has helped. Now I am back with: 1/1 (100.00%) /usr/bin/python -tt test/sconstest-is

Re: [Scons-dev] Testing non-core tools

2013-07-27 Thread Russel Winder
Dirk, […] >1.) Either add 'toolpath=["."]' to the environment definition, or >2.) put the protoc.py in a default path, where it gets picked up > automatically: > >test.file_fixture('../protoc.py','site_scons/site_tools')# > untested! 1 works, I haven't tried 2 since 1 worke

Re: [Scons-dev] Testing non-core tools

2013-07-27 Thread Dirk Bächle
Russel, On 27.07.2013 13:00, Russel Winder wrote: […] Does this help? Yes, but… is this the right paradigm to get people writing tests for non-core tools to use? I can become happy with "yes", but I just wonder if there is an easier way. I think this would require a definition of what exactly

Re: [Scons-dev] Testing non-core tools

2013-07-27 Thread Russel Winder
Dirk, On Sat, 2013-07-27 at 13:30 +0200, Dirk Bächle wrote: […] > I think this would require a definition of what exactly entails the term > "right paradigm". Also, calling for an "easier way" instinctively makes > me ask: "For the users, or the developers?". I think "user" and "developer" here

Re: [Scons-dev] Testing non-core tools

2013-07-27 Thread Dirk Bächle
Russel, On 27.07.2013 14:09, Russel Winder wrote: Dirk, On Sat, 2013-07-27 at 13:30 +0200, Dirk Bächle wrote: […] My irritant here is that the test SConstruct is not the same as would be used in a real project. Given all SCons tests are effectively system tests, I tend to prefer the code of the

Re: [Scons-dev] Testing non-core tools

2013-07-27 Thread Russel Winder
Dirk, On 2013-07-27, at 13:30+0100, Dirk Bächle wrote: > I don't want to appear nit-picky, but when you set up an SConstruct for a > project that uses a locally packaged Tool module (like your protoc.py, in the > top-level folder), you have to specify "toolpath=['.']" as well. ;) Not not-pick

Re: [Scons-dev] Testing non-core tools

2013-07-27 Thread Dirk Bächle
On 27.07.2013 15:51, Russel Winder wrote: [...] But the need to specify the -e to test non-core tool packages is already a marker that they are being handled specially. Also from the above tool sources are special structures and deserve special support. Given tests must run under the test fram