Re: [IMP-dev] building of lone modules/applications/biological_systems
To: List for IMP development <>
Subject: Re: [IMP-dev] building of lone modules/applications/biological_systems
From: Daniel Russel <>
Date: Mon, 13 Dec 2010 13:38:44 -0800
Reply-to: List for IMP development <>
>> That wouldn't be that hard to do if people wanted it. It would obviously
> be difficult to do that for every combination of architecture, build
> flags and dependencies, however
Aren't all lab desktops running the same distribution? Given that, there is no dependency/variation issue (as there is no reason to not have all the required rpms installed), just one fast and one release are needed. Likewise, presumably for 64 bit machines on the cluster.
> (and old versions will become unusable
> if any dependency's API changes, when there is a Fedora update, etc.).
Yes, it is a problem when packages are updated during the day. But it breaks individual builds of IMP too. And as it doesn't seem to happen too often, just rebuilding during the day when it does probably should handle it painlessly. And it could, presumably, be solved by timing desktop updates with builds.
> You also can't patch a nightly build to fix a problem in it, or tweak
> something in it to see how it affects your code.
Of course. It only makes sense for people who are not modifying core parts of IMP frequently. But, at least judging from commits, most people using it don't. And one can often check out a single module and fiddle with it (except for memory layout in algebra and the kernel), while using the build of the rest of IMP.
> What do you gain over
> simply building your own copy of IMP and point your lone module's
> config.py at that? Obviously you can check out whichever version from
> SVN you like and update it as frequently (or infrequently) as you choose.
Currently the cost for moving between IMP versions is quite high due to the compilation time. With such a setup, one could update to the new version quite quickly (and revert quickly when there are problems), which I suspect would make people do it more often. And that means that changes that cause trouble will raise flags sooner.
It also makes it easier to track down bugs and performance hiccups as one can easily try old versions (at least back to the last boost upgrade), something which I find prohibitively painful currently.