Daniel Russel wrote:
> The two choices that I see which satisfy these criteria are:
> - embed all data into the data section of the libraries.
I don't like this option so much, since it makes it harder to modify the
libraries (you'd have to rebuild IMP each time). Users that get prebuilt
binaries would never be able to inspect these data files. Plus, all of
the libraries would get read in to memory whether you need them or not,
increasing the load time and the memory footprint. Finally, if you
stored them as strings and streamed them, you'd end up with two copies
of everything - one the string and the other the actual populated data
structure. So I don't think this is a good idea for anything but very
small data files that are expected to never change (and for those it may
make more sense to store them as static structs anyway).
> - IMP is built with the path to the data stored internally and it must
> be installed before use.
That's the usual Unix way of doing things, so I think we should go for
that. Each module can have a data directory at the same level as the
existing src, include, pyext, etc. directories, and at install time
these files can be placed in /usr/share/imp/modulename/ or similar.
> imppy.sh could go away on most platforms as we could safetly
> embed the paths to the build/lib dir as the library will be rebuild
> before being installed
You'd still need it - or something equivalent - for the Python path, and
on platforms other than Linux and Mac where rpath doesn't work.
Ben
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle