> Daniel Russel wrote: >> One point that I didn't really make clear, is that I don't see that >> the actual library files and the build process necessarily need to >> follow the semantic kernel/package distinction. It may make sense to >> have "Packages", but still build everything into one library and one >> python module. > > Sure, but that's not the model we chose for IMP; it is designed to be > modular. The expectation is that most of those modules will not even > be > hosted in the Sali lab, let alone built into one library. This really has nothing to do with modularity. In either case an outside bit of code is developed and added the same way.
Things should be as simple as possible. Splitting a set of source that is maintained by the same set of people into two libraries just makes it more complicated. If the licensing is different or is the sali lab will not support a bit of code once someone graduates, then it makes sense to separate it. Or, as a much rarer case, if some block of code is so huge that it slows down linking noticeably.
>> The current situation, with having to separately build and install >> impem is really undesirable and does not scale nicely. > > What don't you like about that? There is never any reason not to build everything that can be supported by the current environment and there is no reason to make the user choose what they build explicitly. Users can choose to not use them later.
>> Also, at the >> moment you can't really use thing uninstalled (since the libs are >> scattered across many directories) and you can't easily install IMP >> on >> a mac since the paths don't get set. > > You don't like 'scons install' ? That should put everything in the > right > place. But right now we're very far from a public release, so I don't > really see the point worrying about it excessively. On a mac the horrible command scons embed=$(HOME)/src/EMbed -j $(NUMPROCS) modeller=$(MODINSTALLSVN) usecgal=1\ release=1 install prefix=$(HOME)/fs\ pyextdir=$(HOME)/fs/lib/python2.5/site-packages \ pythondir=$(HOME)/fs/lib/python2.5/site-packages impEM-install
puts things in the right place (you can't put C++ headers in /usr/ include, unless they have changed things in 10.5), but since scons doesn't make the needed calls to install_name_tool you can't link against the installed libraries. Presumably scons will fix this at some point.
My makefile which I use to wrap scons does the following to make linking work:
fix: fixem install_name_tool -id $(INSTALL)/lib/libimp.dylib $(INSTALL)/ lib/libimp.dylib install_name_tool -change kernel/src/libimp.dylib $(INSTALL)/ lib/libimp.dylib\ $(INSTALL)/lib/python2.5/site-packages/_IMP.so install_name_tool -id $(INSTALL)/lib/libimpem.dylib $ (INSTALL)/lib/libimpem.dylib install_name_tool -change kernel/src/libimp.dylib $(INSTALL)/ lib/libimp.dylib\ $(INSTALL)/lib/libimpem.dylib