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.
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?
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