Greg,
This isn't a big issue for me, per se. My motivation for asking
was part of thinking about cleaning up the build process a little and
looking ahead to the possibility that people might want to build binary
packages, either for public distribution or for internal use (IT types
get all excited about package management and that sort of best-practices
thing).
Thanks,
Andy
Greg Landrum wrote:
Dear all,
On Mon, Jul 14, 2008 at 7:00 PM, Andrew Fant <[email protected]> wrote:
While we're on the topic of compiling, what is it from the boost sources
that rdkit needs to compile that isn't in the various linux binary
packages? On ubuntu, I've installed all the libboost-dev types, and I
point BOOST_BUILD_PATH and BOOSTHOME to /usr/share/boost-build (which is
where all the internal jam files and such are kept), but the compile
bombs out complaining that jam can't find a jamfile in
/usr/share/boost-build. I assume it's looking for the one that is used
to actually build boost from source, but my boost-fu is weak. Does
rdkit actually try and force a recompile of boost at build time, or are
there just bits and pieces of the source that it wants to assimilate
into its own tree?
I did a bit of looking around and found a quite useful thread on this
topic here:
http://www.nabble.com/Using-boost-libraries-on-Ubuntu-through-Boost.Build-td15333685.html
What I take from that thread and some other information I've found :
It would (at least theoretically) be possible to modify the existing
RDKit build files in order to allow the system to be built on machines
that have boost installed from packages instead of from source. In
order to do this, however, the location of the headers, libraries, and
boost.build itself will need to be provided. I guess this would be
done as environment variables. Additionally, some work would have to
be done to make sure that the correct libraries are linked (e.g.
debugging when you do a debug build).
It seems to me like the gain from making these changes is pretty
minimal compared to how much additional complexity they would
introduce, but I'm open to discussion.
-greg
