I have written some code to use BALL to
read PDB files and turn them in to particles and a hierarchy (and to
evaluate MD energy for such a hierarchy). Keren wanted to use this too.
Do you have a preferred SVN structure/location for this sort of thing?
Something like trunk/IMP_BALL with include and src directories? And
pyext too I guess.
Sure, my policy is, roughly speaking: if it doesn't break the core unit
tests, put it in. Better to have it in SVN where we can poke holes in it
than it to live on your laptop for ever.
But this may be an opportune point to discuss the layout of the IMP
repository. Right now it looks basically like:
imp
libsaxs
src
doc
mdt
bin
src
doc
pyext
test
new_imp
bin
IMP
tests
impEM
rsr
doc
pyext
od_dope
src
doc
pyext
test
tnt
python
test
tools
The top-level directories are independent modules which are built
separately but use a shared set of build scripts (in the tools
directory). libsaxs is Frido's SAXS module, which plugs in to Modeller;
mdt uses the Modeller C and Python interfaces; od_dope uses the Modeller
C interface; tnt and new_imp use the Modeller Python interface. new_imp
is essentially what Bret turned in before he left, and which Daniel,
Keren and I are currently working on.
The projects have similar sub-directories: bin for generated binaries;
src for C/C++ source code; doc for documentation; pyext for Python
extensions; python for pure Python code; test for testcases. However,
new_imp uses 'IMP' as its source code directory, and the tests live
under that. new_imp also contains some sub-projects, such as Keren's
impEM interface and Bret's RSR (Restrainer web interface).
As Daniel pointed out, new_imp's naming is a little inconsistent (e.g.
imp/new_imp/IMP to get to the sourcecode) so what about renaming the IMP
subdirectory to src, and the new_imp top-level directory to kernel (or
perhaps base) ? Dependent projects such as impEM and rsr would then
become top-level directories:
imp
libsaxs
mdt
kernel
bin
src
test
doc
pyext
rsr
impEM
od_dope
tnt
tools
This scheme would, however, require you to manually handle dependencies
between the projects (e.g. impEM and rsr would be independent projects)
but that's not a huge hurdle - just run 'scons' in the kernel directory
before running 'scons' in the impEM directory. A slightly more radical
rearrangement could look like
imp
libsaxs
mdt
bin
kernel
src
test
doc
pyext
rsr
impEM
od_dope
tnt
tools
and use a top-level build system which would track dependencies between
projects, staging binaries and libraries for all IMP projects to the bin
directory (but the downside is the targets are a bit more wordy - e.g.
'scons kernel', 'scons kernel-test', 'scons 'impEM', scons 'impEM-test'
rather than just 'scons' and 'scons test' in the kernel and impEM
directories).
Thoughts?
There is, of course, also the issue over whether libsaxs, mdt, od_dope
and tnt belong here or in their own repository. My understanding is that
the Grand Plan is that they'll become part of IMP eventually, which is
why they're there. But if we want to distribute them under a non-free
license for any reason, it might make sense to put them in a separate
repository in the future.
Ben
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle