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.orghttp://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