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

[William Blevins]

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.
>
>
>
> Cheers
>
> Ben
>
>
>
> _______________________________________________
> 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/20150304/8e3e5eb4/attachment-0001.html>