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