I would be happy if you just concentrated on updating the documentation for the current supported builds so that they're self-contained and foolproof. I'm thinking here mainly of the Windows build - what boost stuff do I need to download exactly? Also, the Linux build tells me to read the boost documentation, but I don't want to do this.
Noel 2008/7/16 Greg Landrum <[email protected]>: > 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 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rdkit-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/rdkit-discuss >
