Hi Greg, thanks for integrating those files so quickly.
>> * boost-numeric-bindings: [...]. > > 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. Yes, I undestand your concerns. If the boost-numeric-bindings had a binary library file to link against or if they were needed in any other phase than at build time I would have considered redistributing an additional third-party package a sub-optimal choice. On the other hand, since these bindings are not yet part of the official Boost Libraries their development cycle, versioning, packaging seemed a bit confusing to me. Redistribution simplifies some operations, but maybe one could also ask on the boost-ublas mailing list for advice on this subject. >> * 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 think I've seen something about the management of installation details while searching the cmake docs, but at the moment I preferred to postpone the problem. I'm really glad you reviewed this part, I verified that most tests ran successfully, but my environment seemed quite untidy (some tests worked from the build directory, some others if executed the "old" way :-) Now that a reference configuration is available from a dedicated svn branch I will try to understand the test suite and installation process a bit better. > 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. Ahhh... I see.. I think a clean, acceptable alternative might eventually be available for 2) but I was totally unaware about 3) .. I must go fix the runtime environment of my rdkit installation then.. More exactly, what components depend on $RDBASE at runtime? >> 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. No need to. I'm just glad to know it worked smoothly and was useful. Thank you to you for this toolkit, I'm still discovering subdirectories with features and/or components I didn't know about. Best regards, Riccardo
