[Scons-users] Announcement: SCons core changes ahead...

Robert Zeigler robert.zeigler at gmail.com
Mon Jul 7 15:38:55 EDT 2014


On Jul 7, 2014, at 7/72:10 PM , Dirk Bächle <tshortik at gmx.de> wrote:

> Hi there,
> 
> after releasing SCons v2.3.2, the developer team is now planning the next steps. In the background we're already working on a version that runs under Python 2 *and* 3, and have started redesigning the handling of Tools a little bit. Both of these items will need some more time, so we'd like to take care of SCons' performance instead for the next release.
> 
> We have prepared two major additions that will hit the development repo at Bitbucket soon. They will probably have very little impact (none, for the standard user), but might break some of your SConstructs/SConscripts and Builders. That's why we're making this announcement as early as possible...to give you enough time, if you should need to prepare for the oncoming changes:
> 
> 1.) Speed: A series of profilings (see http://scons.org/wiki/WhySconsIsNotSlow ) has uncovered that clean builds in SCons suffer badly from the fork() call, which is used by the subprocess module to spawn separate processes when executing single build commands. For Posix-like systems we'll add a wrapper module, that redirects the subprocess calls to the more lightweight posix_spawn().
> 
>    This change can have an impact on your local code if you're redirecting the SPAWN method in SCons environments your own way.


Can you expound on this a bit? I have some situations where I override the SPAWN environment variable to point to a custom method, so I’d like to understand the implications a bit better. In my case, I’m usually kicking off long-running/resource-intensive processes where resource allocation is managed by an external queueing system (SLURM, OGE, etc.).

Thanks,

Robert


More information about the Scons-users mailing list