I find it best to preemptively build IMP (and keep it up to date). eg on my desktop IMP is updated and built each night by cron, primarily for benchmarking, but it has nice side effects when it comes to building small changes during the day. And likewise, I just build on my laptop when I don't need it, so that I don't have to wait when I do. Not as nice as something like ccache and works best when you are the primary person breaking svn :-), but it is relatively easy and means I don't often wait (other than for the swig wrappers to be rebuilt).
As for the swig wrapper, I have another idea to try for bypassing the dependency checking on pre-updated files, but haven't gotten a chance to try it yet.
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 <> 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
>> --
>> http://salilab.org/~ben/
>> "It is a capital mistake to theorize before one has data."
>> - Sir Arthur Conan Doyle
>> _______________________________________________
>> IMP-dev mailing list
>>
>> https://salilab.org/mailman/listinfo/imp-dev
>>
>
> _______________________________________________
> IMP-dev mailing list
>
> https://salilab.org/mailman/listinfo/imp-dev