Given that most of the IMP changes are to quite peripheral code, I think it is OK to only update IMP occasionally (say weekly) when only making changes to a particular module. SVN will notify you if the file was changed elsewhere and otherwise it is cheap to clean up the rare issues.
On Nov 23, 2010, at 6:06 PM, Dina Schneidman wrote:
> Thanks Ben. I am already familiar with the way compilers and builders > work, so these suggestions are used by default. And I am happy with > the speed of my computer, 8 cores and 32G memory are not that bad :) > Related to Daniel's question, I want to distinguish between working on > the code and committing the code. > When we work on the code, the re-build is indeed very local, so it's > not a big deal. > But when we commit code, we have to update our IMP version (in order > to have the latest version), everything has to be re-built, since IMP > main modules (kernel, core, etc..) change almost everyday. And this > is where most of the compilation time is spent. > Also as Daniel pointed out, swig does takes lots of time to build, and > while I can skip these builds when I work on C++ code, I can't do it > when I commit the code and have to run python tests. > > On Tue, Nov 23, 2010 at 4:19 PM, Ben Webb ben@salilab.org wrote: >> 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 >> -- >> ben@salilab.org http://salilab.org/~ben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev