[Scons-users] Hi, wondering about possible speed ups to scons

Kenny, Jason L jason.l.kenny at intel.com
Wed Mar 4 19:43:27 EST 2015


I think this is a good idea. I was looking at something like this in Parts, once I do some refactoring.

Ideally this is a modification of the interactive mode in SCons in which SCons load all the information and via a build command start rebuilding based on what changed on disk.

Jason

From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of Schleimer, Ben via Scons-users
Sent: Wednesday, March 4, 2015 5:53 PM
To: scons-users at scons.org
Subject: [Scons-users] Hi, wondering about possible speed ups to scons

Hi Y'all,
   First of all, I'd like to say that I use SCons all of the time for my C++ projects and it's by far the best build system I've had the pleasure to work with. I especially like the ease of using the Qt4 tools and precompiled header support, yada yada yada...

Secondly, I've been thinking about all of the criticism aimed at scons for not being fast enough.
I understand that python is inheritantly slow (ignoring cython, etc..) but it seems like SCons could easily design it's way out of this problem.

I'm wondering if the design change for SCons I'm about to propose has been proposed before:

1) Create a scons daemon (sconsd) that stays resident and watches a particular SConstruct file and all of its generated dependencies. Whenever any of the dependencies change or is deleted, scons updates the dependency graph in the background.

2) When the user actually runs scons to compile, the dependency graph is ready to be immediately traversed and all of the Nodes built.

Thoughts? Ideas?

Anyway, thanks for an awesome piece of software.

Cheers
Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150305/2c7c6ea1/attachment.html>


More information about the Scons-users mailing list