The major obstacle is that those builds take forever to build, and you
really don't want to wait for them, when you want to commit 3 lines of
code.
There are several things you can do as a developer to avoid this:
1. Use the -j flag to scons (just like for make) to parallelize the
build. e.g. -j4 or -j8 (depending on how many processors your machine has).
2. Work most of the time with debug builds. Compiling without
optimization is a lot faster (although the resulting code is slower, of
course).
3. If all you're doing is making small changes to existing files (as
opposed to adding whole new modules and the like) you can skip the
configure stage of each build by running SCons in interactive mode
(--interactive flag).
4. scons is conservative and always errs on the side of a more complete
build if it's not sure, so you may get some unnecessary rebuilds (the
most obvious is that it relinks any dynamic library if any of its
dependencies are rebuilt). I'm assuming this and the rebuild of SWIG
modules are the "deep flaws" that Daniel alludes darkly to, since I'm
not aware of any others. So for example, if you modify a single file in
the SAXS module, libimp_saxs.so will be rebuilt but also the Python
IMP.saxs module (since it links against libimp_saxs.so). If you're sure
you don't need the Python module to be rebuilt, just ask scons to build
libimp_saxs.so itself, i.e. "b build/lib/libimp_saxs.so" from the scons
--interactive prompt. (In principle "b saxs-lib" should do the same
thing if the alias is set up properly, but also work on Macs and Windows
systems.)
Otherwise, sorry, compiling C++ code is slow. Ask for a faster computer. ;)
Ben
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle