Subject: Re: [IMP-dev] NBL cleanup and other small patches
From: Daniel Russel <>
Date: Tue, 6 May 2008 18:42:07 -0700
Reply-to: List for IMP development <>
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.
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: