Re: [Scons-dev] compiler lookups, particularly windows
The reason it was split is because there's a maximum runtime per job on appveyor and without splitting into 4 our regression tests on windows exceed the limit and were getting killed. Currently not a way to tie the tools used to the builders run by each build. That could be useful for test runtime, and when users are trying to squeeze the last bit of performance out of scons.. Though there may be more generally useful features/bugs to spend time on. -Bill On Tue, Oct 30, 2018 at 3:53 PM Mats Wichmann wrote: > On 10/30/18 2:34 PM, Mats Wichmann wrote: > > > I'm looking at the appveyor page > > https://ci.appveyor.com/project/SCons/scons/history > > this is a pretty typical display for a build: > > Failed 5 hours ago in 4 hr 44 min > > the build is divided into four chunks, but I'm not seeing the purpose of > that since they apparently still run sequentially, since it's a "free" > product, we get only one execution stream. > > slow builds don't critically hurt this project since there isn't > honestly that much change activity. still... > > > > > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] compiler lookups, particularly windows
On 10/30/18 11:30 AM, Bill Deegan wrote: > What would you propose? if I had a formed proposal I would have made it, instead of asking :) > > 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. I found that when I tried, because there are often not completely obvious tools in play (at least until you get familiar with what everything will need). is there some way system config details could be saved and signed in the same way that build products can be recorded and cached, and if there's reason to believe the system has not changed, reuse those? Or does that risk heading in the direction of "builds may not be repeatable"? ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] compiler lookups, particularly windows
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 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
