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

[Schleimer, Ben]

Hi Y'all,
    I couldn't resist looking for python file watching packages and 
found Watchdog Watchdog — watchdog 0.8.2 documentation
|   |
|   |   |   |   |   |
| Watchdog — watchdog 0.8.2 documentationWatchdog Python API library and shell utilities to monitor file system events. Directory monitoring made easy with A cross-platform API. A shell tool to run commands in response to directory changes.  |
|  |
| View on pythonhosted.org | Preview by Yahoo |
|  |
|   |

  came up as the best one. I tested it's helloworld example on ubuntu and it works like a charm. 
It has some unfortunate dependencies but at least it demostrates that cross-platform file watching is pretty straight forward in python
CheersBen
 

     On Wednesday, March 4, 2015 5:03 PM, William Blevins <wblevins001 at gmail.com> wrote:
   
 

 I'm not sure how I like this idea.  Seems rather intrusive and puts a lot of filesystem IO into background processes.  I'm also not sure how sconsd would find SConstruct files or go about doing file monitoring on such a large set of inodes, but maybe its less involved than I think. How do revision control systems track files?  Also, will this be easy to keep platform agnostic?  I doubt it.
SCons isn't that slow really.  People often assume SCons is slow simple because isn't printing out anything when its simply examining a node.  Since all the make builds I'm familiar with always print out junk even if the build system is just changing build directories, it is obvious to the most casual observer (read idiot) that if the terminal isn't flooded with text, then SCons must be slow.  It's actually embarrassing how shallow human perception can be.
In all honestly, after getting slots and process wrappers finished,  I think we should worry more about design like the toolchain enhancements, integrating PARTS, etc.  I'm still chomping at the bit for Java toolchain rework, but I'm slow at getting my change proposal laid out.  When I finish this pile of RL paperwork, I'll get back on that.
My 2 cents,William
On Wed, Mar 4, 2015 at 7:43 PM, Kenny, Jason L <jason.l.kenny at intel.com> wrote:

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. CheersBen 
_______________________________________________
Scons-users mailing list
Scons-users at scons.org
https://pairlist4.pair.net/mailman/listinfo/scons-users




_______________________________________________
Scons-users mailing list
Scons-users at scons.org
https://pairlist4.pair.net/mailman/listinfo/scons-users


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