What would you propose? I've spent some time adding: DefaultEnvironment(tools=[]) and Environment(tools=[] or just list of tools needed by test) In order to speed up windows tests.
These are generally pretty effective, though getting a minimal set of tools per test can be time consuming. -Bill On Tue, Oct 30, 2018 at 8:08 AM Mats Wichmann <m...@wichmann.us> wrote: > > Yesterday I tested a small change which improves finding an alternate > build suite on windows (visual studio being considered primary, build > tools being "other"). In running the tests, I unintentionally left a > debug statement in the file and in the log saw this: > > XXX FOUND VC: C:\Program Files (x86)\Microsoft Visual > Studio\2017\BuildTools\VC > > a total of 1519 times. > > some of this process is kind of expensive... once the lookup that > generated that message has worked, one of the "vcvars" scripts is run to > find the actual needed executable and any other details - there's > already a comment in the code this is an expensive operation ("not > cheap"), and there's some effort to speed it up. > > Is it worth trying to figure out any way to do better at this? It makes > test runs on Windows slow, and in particular it means the Windows CI > build, which is four runs back to back for different Python versions > take a really long time - to the point where often when you go see if > your build passed, Appveyor is waiting to even start a build because > some other build hasn't finished yet. > _______________________________________________ > 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