[Scons-users] SCons very slow on GitHub actions

[Mats Wichmann]

On 4/30/25 23:19, Leonard de Ruijter wrote:
> Does SCons perform extensive IO during the reading phase and if so, 
> where exactly? Is that in the workspace directory, or in a particular 
> cache dir.

Not particuarly, no - it depends on the project size.  In computing 
signatures, it reads all the sources, which may also be processed 
looking for implicit dependencies. If there are existing copies of 
targets (not likely in a CI build), it has to compute hashes for them, 
too. In a bit project with thousands of C++ files, sure, there's quite a 
bit of I/O.  For the build of the examples you set up, there's almost 
nothing to process.

Many of the performance optimizations are designed for human "repeat 
customers" - you can reuse information from previous builds, avoid 
rescanning for deps, and in the case of the msvc setup, you can reuse 
cached versions of that information, too.  You can of course make that 
persistent for a CI build but I imagine it takes a bit of work.

The caches are where you put them - the argument to CacheDir, and the 
value given for
SCONS_CACHE_MSVC_CONFIG; everything else happens local to the build dir 
*except* when a temporary directory is needed, as in when the TEMPFILE 
scheme for long command lines needs to create a response file - that 
will default to the a place chosen by Python's tempfile module, but you 
can control that, too, either by setting the environment's %TEMP%, or by 
setting SCons'  env['TEMPFILEDIR'].

> I have tried moving the repo to a dev drive as with this action: 
> https://github.com/marketplace/actions/setup-dev-drive
> 
> But that didn't make a difference.
> 
> I discovered though that when running an older SCons on server 2022, it 
> started firing errors about de Visual Studio compilers not found, but 
> then stopped script reading pretty quickly. So I'm pretty sure it has to 
> do with the visual studio part.

I'd agree that something to do with the msvc setup is by far the most 
likely culprit. A quick experiment might be to take some of the examples 
you already fiddled with and modify them to build with mingw so the 
default msvc initialization is bypassed.  That shouldn't need more than:

env = Environment(tools=['mingw'])

in the SConstruct