Dear Riccardo, I'm CC'ing the discuss mailing list on this because I think others from the community will be interested in this work.
Others: Riccardo has extended the prototype cmake build system I put together so that it works for the full RDKit, not just the minimal branch. This is now available on the following branch: https://rdkit.svn.sourceforge.net/svnroot/rdkit/branches/CMake_28Sept2009 Current status: - Linux: builds and all tests pass - MacOS: builds and all tests pass except testGrid - Windows: untested; I will do this in the next few days Discussion of some remaining details below: On Fri, Sep 25, 2009 at 4:41 PM, Riccardo Vianello <[email protected]> wrote: > Hi Greg, > > I tried extending the cmake-based build system available from the > minimal branch to the latest version available from the main trunk > (looked like a good exercise to actively learn something). There are a > few ideas I think could be considered during this phase, in order to > simplify the build process and make the distribution more friendly (to > linux users at least, I understand some aspects are not equally > relevant on other OSs).. > > * boost-numeric-bindings: with cmake, building against the > system-installed boost libraries is quite straightforward, but (to my > knowledge) no linux distribution currently packages the boost numeric > bindings. Since it's just composed of header files and since it's only > required to be available at build time (am I correct?), I think this > component might be a potential good candidate for an addition to the > $RDBASE/External directory (alternatively, boost-numeric-bindings > might be packaged independently, and a custom cmake module might check > its availability at build-time.. But my impression is that several > reasons could make this option less convenient and - depending on the > upstream boost-numeric-bindings development process - not necessarily > cleaner than aggregating it in bundle to RDKit). For now I've put the most recent version of the numeric bindings in External, as you suggest, and checked this into svn. For the actual release we could either keep things this way or require the user to download the numeric bindings and extract them in the External directory themselves. There are arguments for and against both of these approaches, but I basically agree that the current (on trunk) requirement that the user extract the numeric bindings over the system (usually) boost is not really idea. > * if the main CMakeLists.txt file is placed in the topmost directory, > ${CMAKE_SOURCE_DIR} may easily replace $RDBASE at build time. At the > same time it would seem more user friendly to me. usually, the > workflow is just unpack, cd, configure/cmake, and make.. looking for > the right place inside the sources directory tree and moving to a > directory named Code to manage the build from there is not critical > but it is a bit unexpected and sounds a bit "non-standard" to me.. I > think most people would appreciate if the build environment had its > root in the topmost directory. Actually, I'd also like to reduce the > number of environment variables one might set the wrong way or forget > altogether. Agreed; and I like the way you've done this. The build process now consists of: 1) set $RDBASE (discussion below about why I'd rather keep this env var) 2) mkdir build;cd build 3) cmake .. 4) make install 5) make test I'd guess we can probably simplify this even further, but it's not bad as it stands. > * re-engineering of the test-suite: together with building "out of the > source tree" I would like to be able to install files to more standard > locations (eventually under a user-provided prefix). Unfortunately, if > I understood it correctly, several tests expect build and > installation to occur inside the source tree. This way, a > build-install-test sequence is enforced, while I would usually expect > to perform tests prior to the installation step (and avoid > installation altogether, in case tests failed). Moreover, some tests > currently rely on $RDBASE and make this environment variable necessary > again. The tests that expected build and test to happen in the source tree were incorrect. These should have been using $RDBASE to find their test data. I fixed those in svn, so a pure out-of-source build works now. Installation of the shared libraries and python modules to a user-specified location should also work, but we will need to figure out how to copy data files with that install. This is part of cmake I haven't figured out yet. > I hope these ideas do not sound too naive, please forgive my lack of > familiarity with the project in case some of these things had their > good reasons to be the way they are and are not supposed to change. This is a good place for an explanation of what $RDBASE is used for: Uses of $RDBASE: 1) By the build system to locate include files and decide where to install things to. 2) By the test code to find input and output data. 3) By some runtime components to find default parameter files. Use 1) could (and should) be handled within the build system (i.e. via CMAKE_SOURCE_DIR), but I think 2) and particularly 3) are best done using the environment variable. > Finally, with regard to the cmake port.. I'm very new both to rdkit > and cmake, there are risks that reviewing my attempt to the port might > cost more than doing the work from scratch.. but since it took some > hours, I've got it here, and since it seems to produce a mostly > complete (and mostly sane) build, it might even provide a > better-than-nothing starting point, I don't know.. and I'm therefore > attaching a tarball [*]. Please, feel free to have a quick look at it, > and reuse it or discard it at your best convenience. Using your files directly worked almost perfectly; I only had to make small changes to get things working for me. You saved me a lot of time by doing this! I cannot thank you enough. Best regards, -greg
