On Dec 13, 2010, at 11:08 AM, Javier Velazquez wrote:
> > There is one thing that I didn't understand. If you develop on that > directory, can you commit from it to the proper svn directory? What I > mean is: > > If I am developing in ~/mydir_dir_where_i_work/src/my_file.cpp , when I > commit, is it going to be placed in imp/modules/mymodule/src/my_file.cpp > on the repository? If not, I see a potential problem of duplicated files. Files get committed wherever svn says they go. As a couple examples: - one could have a module that is not in the imp svn but in another svn repository (eg my npc module). I then have a directory (say npcdir), containing a checkout of my npc module (and links to the SConstuct and scons_tools and an appropriate config file pointing to a shared IMP build). I can then build my npc module ("scons -j 4") using the IMP nightly build for the rest of IMP and test it ("scons -j 4 npc-test"). Any changes I commit go to my npc svn repository.
- alternatively, only could be interested only in, say saxs from the IMP svn repository. You could then have a directory containing a checkout of the saxs module from the IMP repository ("svn co https://svn.salilab.org/imp/trunk/modules/saxs") and the sconstruct and scons_tools. Saxs can be built in isolation against the nightly build using "scons -j 4" and tested using "scons -j4 saxs-test" (the nightly build of saxs will be ignored). Changes made to saxs here would, when committed, go into the IMP repository.
Does that make sense and make things clearer?
> > Another thing that I don't get is the tests. Assuming a nightly build > for everyone, could I assume that other modules are tested, and > therefore only test my module? Yes. The idea would be that anything in the IMP svn would be tested as is currently the case (and the builds are exposed). Modules and things which are not in the IMP svn could then be tested on their own (with scons "modulename-test").
> > On 12/13/10 8:54 AM, Daniel Russel wrote: >> IMP now supports building of modules/applications/biological_systems without a full checkout of IMP svn. This means that you can create a directory containing only your module/application/biological_system (henceforth mabs) in a subdir, link the IMP SConstruct and scons_tools entries, make your config's includepath, libpath, pythonpath, and swigpath point to valid IMP headers, libraries, python modules and swig files, you can then happily build and test your module without >> - dealing with scons randomly rebuilding parts of IMP >> - having to compiling IMP yourself at all >> - sit through scons setting up other modules >> >> This makes sense to do if >> - you are not working on IMP core code (just adding stuff to your own mabs or working on a module like saxs or multifit that is not used by other modules) >> - what you are doing is not so bleeding edge that you need IMP updates more than once a day or so >> - we provide some sort of usable nightly build... >> >> My suggestion for how we could best take advantage of this would be to have useful nightly builds (release and fast with all dependencies against the desktop linux version) installed into a shared location each night in a directory labeled by the svn version or the date (eg /diva1/imp/release/12_11_2010). You could then point your local config.py at a given date's build rebuild only your code. Updating to a newer version of IMP would simply requiring changing where your config.py is pointing and rebuild only your code (so very fast). Having a repository of old builds of IMP would be very nice (I think Dina would agree) in tracking down changes in behavior and performance. >> >> The same thing could be done on the cluster. I'm not sure if there is much one could do with laptops though. >> >> Does this sound useful? >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > -- > Javier Velazquez > Postdoc at Salilab, UCSF > 1700 4th st. Byers Hall, office 503. > 94158 San Francsico > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev