On 11/23/10 11:10 AM, Dina Schneidman wrote: > 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