All, On Feb 4, 2013, at 11:31 AM, "Kenny, Jason L" <[email protected]> wrote:
> > I am not going to say this is an easy problem to solve ( dealing with this in > Parts, all the time) > > Depending on how you view the "tool" to work I find that I need to test did > tool X: > 1) correctly detect that it does not exist > 2) detect that it does exist > 3) given that it does exist, is the environment correctly setup to build with > the given tool. > 4) I am a little more complex, as I have Parts support different > version/targets platform combination. So testing different version selection > is needed for me as well. ( My current headache is how to test for certain > SDKs such as the NDK to make sure the test run only if this exists, without > having to set up some super path before the tests runs, or binding to a > certain version of the NDK) > > If you setup for the different D tools is like the C++ cases, ie we have > intelc, msvc, gcc, etc... then each case can be tested independently from > each other. It could be done on a single machine with the D tools installed. > If this is a single D tool that deal with all cases. That would be hard to > test, it would probably need lots of VM, so you could control which D > compiler is being used. Adding to the complexity is that MS licenses are not free.. > > I am only thinking that it might not be so hard given we have different tool > files for the different D compiler cases. One machine for a given platform ( > windows, linux, mac, etc) can test the exists cases, while on can deal with > all cases of tools not existing. Would it make sense to have the test infrastructure take an environment variable on tools to not initialize? And/or for SCons itself, perhaps also a command line argument? This would simplify the # of VM's needed to test the possible or reasonable combinations? -Bill _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
