rdkit-devel — Developers information and discussion.

[Rdkit-devel] [PATCH 1/3] Locate python's sitearch directory and install python wrappers there

[Gianluca S. <gi...@gm...>]

---
 CMakeLists.txt                      |   13 +++++++++++++
 Code/cmake/Modules/RDKitUtils.cmake |    2 +-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0cfb0b6..8183c27 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -45,6 +45,19 @@ if(RDK_BUILD_PYTHON_WRAPPERS)
   find_package(NumPy REQUIRED)
   include_directories(${PYTHON_NUMPY_INCLUDE_PATH})
   find_package(Boost 1.39.0 COMPONENTS python REQUIRED)
+
+# Determine correct installation directory for Python bindings
+# From http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/python.cmake?revision=11014
+  execute_process(
+    COMMAND
+    ${PYTHON_EXECUTABLE} -c "from distutils import sysconfig; print sysconfig.get_python_lib(1,0,prefix='${CMAKE_INSTALL_PREFIX}')"
+    OUTPUT_VARIABLE PYTHON_INSTDIR
+    OUTPUT_STRIP_TRAILING_WHITESPACE
+    )
+  message("Python Install directory ${PYTHON_INSTDIR}")
+
+  install(DIRECTORY rdkit DESTINATION ${PYTHON_INSTDIR})
+
 else(RDK_BUILD_PYTHON_WRAPPERS)
   find_package(Boost 1.39.0 REQUIRED)
 endif(RDK_BUILD_PYTHON_WRAPPERS)
diff --git a/Code/cmake/Modules/RDKitUtils.cmake b/Code/cmake/Modules/RDKitUtils.cmake
index 993488a..3bfcd6f 100644
--- a/Code/cmake/Modules/RDKitUtils.cmake
+++ b/Code/cmake/Modules/RDKitUtils.cmake
@@ -46,7 +46,7 @@ endif(MSVC)
                           ${PYTHON_LIBRARIES} ${Boost_LIBRARIES})
 
     INSTALL(TARGETS ${RDKPY_NAME} 
-            LIBRARY DESTINATION ${RDKit_PythonDir}/${RDKPY_DEST})
+            LIBRARY DESTINATION ${PYTHON_INSTDIR}/rdkit/${RDKPY_DEST})
   endif(RDK_BUILD_PYTHON_WRAPPERS)
 endmacro(rdkit_python_extension)
 
-- 
1.7.1.1

[Rdkit-devel] [PATCH] add STATIC keyword to force static linking

[Gianluca S. <gi...@gm...>]

Hi all,
my packaging effort exposed some things that could be improved in the
build system, I will post some patches to address the issues I managed
to overcome.

The first one follows, basically, three libraries linked another
statically generated library, but failed to declare it properly
resulting in breakage when building with a global
"-DBUILD_SHARED_LIBS=TRUE".


commit a414770e549590f196c0bca05fead81d5cb7716b
Author: Gianluca Sforna <gi...@gm...>
Date:   Sat Jul 10 18:12:38 2010 +0200

    Add STATIC keyword

diff --git a/Code/ML/Cluster/Murtagh/CMakeLists.txt
b/Code/ML/Cluster/Murtagh/CMakeLists.txt
index 878953f..1ac93c1 100644
--- a/Code/ML/Cluster/Murtagh/CMakeLists.txt
+++ b/Code/ML/Cluster/Murtagh/CMakeLists.txt
@@ -1,4 +1,4 @@
-add_library(hc hc.c hcdriver.c)
+add_library(hc STATIC hc.c hcdriver.c)

 rdkit_python_extension(Clustering Clustering.cpp
                        DEST ML/Cluster
diff --git a/Code/ML/InfoTheory/CMakeLists.txt
b/Code/ML/InfoTheory/CMakeLists.txt
index 9e6e05f..9fe55ff 100644
--- a/Code/ML/InfoTheory/CMakeLists.txt
+++ b/Code/ML/InfoTheory/CMakeLists.txt
@@ -1,4 +1,4 @@
-add_library(InfoTheory InfoBitRanker.cpp)
+add_library(InfoTheory STATIC InfoBitRanker.cpp)

 rdkit_python_extension(cEntropy cEntropy.cpp
                        DEST ML/InfoTheory
diff --git a/External/cmim-1.0/CMakeLists.txt b/External/cmim-1.0/CMakeLists.txt
index 808cabc..44559bb 100644
--- a/External/cmim-1.0/CMakeLists.txt
+++ b/External/cmim-1.0/CMakeLists.txt
@@ -1,4 +1,4 @@
-add_library(fastentropy fastentropy.cc misc.cc)
+add_library(fastentropy STATIC fastentropy.cc misc.cc)



-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna

Re: [Rdkit-devel] [Rdkit-discuss] RDKit packaging issues

[Gianluca S. <gi...@gm...>]

On Tue, Jul 6, 2010 at 6:29 AM, Greg Landrum <gre...@gm...> wrote:
>
> If there are no objections, I suggest we take the rest of this
> discussion to the rdkit-devel list since it's probably not one of
> general interest.

Doh... I blame gmail auto-completion for this ;)

>>
>> For instance, libraries (lib*.so.*") are usually to be installed in
>> /usr/lib{64}, binaries in /usr/bin, header files in /usr/include and
>> so on; I believe cmake has all we need to use these these standard
>> paths, but I'd need to dig manuals and/or other projects to find out
>> the correct spell to cast...
>
> I haven't looked into this part at all; hopefully the CMakeLists.txt
> don't have anything that runs counter to this.

It seems this part is not hard, cmake will happily add DESTDIR as a
prefix to any DESTINATION with a relative path, so something like

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0cfb0b6..67a0e7a 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,8 +20,8 @@ option(RDK_BUILD_COMPRESSED_SUPPLIERS "build in
support for compressed MolSuppli
 # Config variables:
 set(RDKit_CodeDir "${CMAKE_SOURCE_DIR}/Code")
 set(RDKit_ExternalDir "${CMAKE_SOURCE_DIR}/External")
-set(RDKit_BinDir "${CMAKE_SOURCE_DIR}/bin")
-set(RDKit_LibDir "${CMAKE_SOURCE_DIR}/lib")
+set(RDKit_BinDir "bin")
+set(RDKit_LibDir "lib${LIB_SUFFIX}")
 set(RDKit_PythonDir "${CMAKE_SOURCE_DIR}/rdkit")

 # defines macros: rdkit_python_extension, rdkit_test

seems sufficient to make it work.

>
>>
>> I think I could uncover more packaging issues as I proceed, but I
>> wanted to kick off some discussions on these points early so we move
>> on quicker toward good linux packages.
>
> I guess the problem is going to be installing the directories
> $RDBASE/{Docs,Projects,Contrib} and what to do about $RDBASE. Would
> putting those into $DESTDIR/share/rdkit and setting $RDBASE to that
> work?

I guess RDBASE should not be necessary once the files are correctly
deployed system wide but I will double check this later.

So, after another session afternoon I managed to produced a binary
RPM; unfortunately it fails installing like:

Resolving Dependencies
--> Running transaction check
---> Package rdkit.x86_64 0:2010.Q2-1.fc12 set to be updated
--> Processing Dependency: libInfoTheory.so()(64bit) for package:
rdkit-2010.Q2-1.fc12.x86_64
--> Processing Dependency: libfastentropy.so()(64bit) for package:
rdkit-2010.Q2-1.fc12.x86_64
--> Processing Dependency: libhc.so()(64bit) for package:
rdkit-2010.Q2-1.fc12.x86_64
--> Finished Dependency Resolution
Error: Package: rdkit-2010.Q2-1.fc12.x86_64 (/rdkit-2010.Q2-1.fc12.x86_64)
           Requires: libfastentropy.so()(64bit)
Error: Package: rdkit-2010.Q2-1.fc12.x86_64 (/rdkit-2010.Q2-1.fc12.x86_64)
           Requires: libhc.so()(64bit)
Error: Package: rdkit-2010.Q2-1.fc12.x86_64 (/rdkit-2010.Q2-1.fc12.x86_64)
           Requires: libInfoTheory.so()(64bit)


I will need to investigate why it claims to need those since they are
statically built so there is actually no *.so


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna

Re: [Rdkit-devel] [Rdkit-discuss] RDKit packaging issues

[Riccardo V. <ric...@gm...>]

Hello,

On Tue, Jul 6, 2010 at 10:16 AM, Noel O'Boyle <bao...@gm...> wrote:
> On 5 July 2010 21:33, Gianluca Sforna <gi...@gm...> wrote:
>[...]
>> Installation - files installed by the "make install" step should
>> honour the "DESTDIR" environment variable; this is becasue packagers
>> need to put files under a certain build directory to be picked up
>> later by the packaging script; this is usually accomplished by setting
>> the env variable DESTDIR or running "make install DESTDIR=xxx". I also
>> need to mention this buildroot (xxx in the example) usually translates
>> to "/" when the package is installed, so default installation
>> subdirectories should be picked according to common standard naming.
>
> AFAIK, with CMAKE you set -DCMAKE_INSTALL_PREFIX for a local install.

yes, but I think prefix and destdir are used in slightly different
ways. Prefix informs the build systems about the filesystem location
where the software will be installed (in order, for example, to
configure the application and/or hardcoding paths), and destdir is
used when packaging to perform a staged installation that reproduces
the final layout under a temporary filesystem location (so that it is
possible to keep track of which files are produced by the installation
process in a reliable way).

If I'm not wrong, cmake supports both mechanisms, but I've got the
impression that the basic issue here is that RDKit is usually
installed inside its own "source" tree, which is fine for personal use
and custom builds, but doesn't integrate very well with a linux
distribution.

Riccardo

Re: [Rdkit-devel] [Rdkit-discuss] RDKit packaging issues

[Greg L. <gre...@gm...>]

Dear Gianluca,

On Mon, Jul 5, 2010 at 10:33 PM, Gianluca Sforna <gi...@gm...> wrote:
> Hi all,
> after spending some time to prepare a Fedora package I have a couple
> remarks/suggestions I'd like to discuss with you in order to make the
> process easier for all the distributions around.

Thanks for looking into this. I've provided some feedback below.

If there are no objections, I suggest we take the rest of this
discussion to the rdkit-devel list since it's probably not one of
general interest.

> Versioning - package manager programs (this is valid in all distros)
> handle updates by comparing versions to decide which one is newer.
> Having names like Q12010, Q22010 etc will break ordering next year
> (Q42010 > Q12011).

Agreed, the internal version number (in
$RDBASE/Code/RDGeneral/versions.h) is already set up this way.

> I suggest you revise how you do name versions; one simple way to avoid
> the issue is to swap year with quarter, so 2010Q4 < 2011Q1. Avoiding
> non numeric versions would be a nice bonus, so you could use to the
> same effect something like "YYYY.MM" (so 2010.12 < 2011.04)

This is ok with me if no one else has objections.

> Installation - files installed by the "make install" step should
> honour the "DESTDIR" environment variable; this is becasue packagers
> need to put files under a certain build directory to be picked up
> later by the packaging script; this is usually accomplished by setting
> the env variable DESTDIR or running "make install DESTDIR=xxx". I also
> need to mention this buildroot (xxx in the example) usually translates
> to "/" when the package is installed, so default installation
> subdirectories should be picked according to common standard naming.
>
> For instance, libraries (lib*.so.*") are usually to be installed in
> /usr/lib{64}, binaries in /usr/bin, header files in /usr/include and
> so on; I believe cmake has all we need to use these these standard
> paths, but I'd need to dig manuals and/or other projects to find out
> the correct spell to cast...

I haven't looked into this part at all; hopefully the CMakeLists.txt
don't have anything that runs counter to this.

>
> I think I could uncover more packaging issues as I proceed, but I
> wanted to kick off some discussions on these points early so we move
> on quicker toward good linux packages.

I guess the problem is going to be installing the directories
$RDBASE/{Docs,Projects,Contrib} and what to do about $RDBASE. Would
putting those into $DESTDIR/share/rdkit and setting $RDBASE to that
work?

Best Regards,
-greg

[Rdkit-devel] Q2 2010 Release

[Greg L. <gre...@gm...>]

Dear all,

I'm very happy to announce that the next version of the RDKit --
Q22010_1 -- is released.

The release notes are below.

The source release and windows binaries (python 2.6 only this time,
please let me know if anyone needs a python 2.5 release) will be on
the sourceforge downloads page:
http://sourceforge.net/projects/rdkit/files/rdkit/Q2_2010/
The files can also be downloaded from the google project page:
http://code.google.com/p/rdkit/downloads/list

I have also updated the online documentation.

Thanks to the everyone who submitted bug reports and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one.

-greg

******  Release_Q22010_1 *******
(Changes relative to Release_Q12010_1)

!!!!!! IMPORTANT !!!!!!
 - There are a couple of refactoring changes that affect people using
   the RDKit from C++. Please look in the Other section below for a list.
 - If you are building the RDKit yourself, changes made in this
   release require that you use a reasonably up-to-date version of
   flex to build it. Please look in the Other section below for more
   information.

Acknowledgements:
 - Andrew Dalke, James Davidson, Kirk DeLisle, Thomas Heller, Peter Gedeck,
   Greg Magoon, Noel O'Boyle, Nik Stiefl,

Bug Fixes:
 - The depictor no longer generates NaNs for some molecules on
   windows (issue 2995724)
 - [X] query features work correctly with chiral atoms. (issue
   3000399)
 - mols will no longer be deleted by python when atoms/bonds returned
   from mol.Get{Atom,Bond}WithIdx() are still active. (issue 3007178)
 - a problem with force-field construction for five-coordinate atoms
   was fixed. (issue 3009337)
 - double bonds to terminal atoms are no longer marked as "any" bonds
   when writing mol blocks. (issue 3009756)
 - a problem with stereochemistry of double bonds linking rings was
   fixed. (issue 3009836)
 - a problem with R/S assignment was fixed. (issue 3009911)
 - error and warning messages are now properly displayed when cmake
   builds are used on windows.
 - a canonicalization problem with double bonds incident onto aromatic
   rings was fixed. (issue 3018558)
 - a problem with embedding fused small ring systems was fixed.
   (issue 3019283)

New Features:
 - RXN files can now be written. (issue 3011399)
 - reaction smarts can now be written.
 - v3000 RXN files can now be read. (issue 3009807)
 - better support for query information in mol blocks is present.
   (issue 2942501)
 - Depictions of reactions can now be generated.
 - Morgan fingerprints can now be calculated as bit vectors (as
   opposed to count vectors.
 - the method GetFeatureDefs() has been added to
   MolChemicalFeatureFactory
 - repeated recursive SMARTS queries in a single SMARTS will now be
   recognized and matched much faster.
 - the SMILES and SMARTS parsers can now be run safely in
   multi-threaded code.

Deprecated modules (to be removed in next release):
 - rdkit/qtGui
 - Projects/SDView

Removed modules:
 - SVD code: External/svdlibc External/svdpackc rdkit/PySVD
 - rdkit/Chem/CDXMLWriter.py

Other:
 - The large scale changes in the handling of stereochemistry were
   made for this release. These should make the code more robust.
 - If you are building the RDKit yourself, changes made in this
   release require that you use a reasonably up-to-date version of
   flex to build it. This is likely to be a problem on Redhat, and
   redhat-derived systems. Specifically: if your version of flex is
   something like 2.5.4 (as opposed to something like 2.5.33, 2.5.34,
   etc.), you will need to get a newer version from
   http://flex.sourceforge.net in order to build the RDKit.

 - Changes only affecting C++ programmers:
   - The code for calculating topological-torsion and atom-pair
     fingerprints has been moved from $RDBASE/Code/GraphMol/Descriptors
     to $RDBASE/Code/GraphMol/Fingerprints.
   - The naming convention for methods of ExplicitBitVect and
     SparseBitVect have been changed to make it more consistent with
     the rest of the RDKit.
   - the bjam-based build system should be considered
     deprecated. This is the last release it will be actively
     maintained.

[Rdkit-devel] Beta of Q2 2010 release up

[Greg L. <gre...@gm...>]

Dear all,

I have tagged a beta of the Q2 2010 release in svn:
https://rdkit.svn.sourceforge.net/svnroot/rdkit/tags/Release_Q22010_1beta1
and uploaded a source distribution and binary for windows (python 2.6)
to the google code page for those who don't want to deal with svn or
building the code themselves:
http://code.google.com/p/rdkit/downloads

Draft release notes are here:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_Q22010_1beta1/ReleaseNotes.txt?view=markup

As usual: if no problems come up in the next week I will go ahead and
do the actual release.

Thanks to everyone who contributed bug reports and suggestions for this release.

Best regards,
-greg

Re: [Rdkit-devel] Building RDKit on Lucid Lynx with distribution packages (x64)

[Greg L. <gre...@gm...>]

Dear Uwe,

On Sun, May 2, 2010 at 7:19 PM, Uwe Hoffmann <uw...@fa...> wrote:
>
> i *assume* that ubuntu have /usr/lib/libboost_regex-mt.so
> If true the question then is: Why was the .so not choosen by the
> configuration process.

I've got the build system configured to use the static version of the
regex library.

-greg

Re: [Rdkit-devel] Building RDKit on Lucid Lynx with distribution packages (x64)

[Uwe H. <uw...@fa...>]

Hi, 

Am Sonntag, den 02.05.2010, 16:46 +0100 schrieb Adrian Schreyer:
> Unfortunately it
> failed, you might want to update the wiki (at least for 64-bit systems
> the packages are not compiled the right way in order to make shared
> objects).
...
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_regex-mt.a(instances.o):
> relocation R_X86_64_32 against
> `boost::object_cache<boost::re_detail::cpp_regex_traits_base<char>,
> boost::re_detail::cpp_regex_traits_implementation<char>
> >::do_get(boost::re_detail::cpp_regex_traits_base<char> const&,
> unsigned long)::s_data' can not be used when making a shared object;
> recompile with -fPIC
> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_regex-mt.a:

i *assume* that ubuntu have /usr/lib/libboost_regex-mt.so
If true the question then is: Why was the .so not choosen by the
configuration process.

regards
   Uwe

Re: [Rdkit-devel] Building RDKit on Lucid Lynx with distribution packages (x64)

[Greg L. <gre...@gm...>]

Hi Adrian,

On Sun, May 2, 2010 at 5:46 PM, Adrian Schreyer <am...@ca...> wrote:
> Hi Greg,
>
> I just tried to compile RDKit on Kubuntu 10.04 amd64 with the
> boost-devel packages that come with the distribution. Unfortunately it
> failed, you might want to update the wiki (at least for 64-bit systems
> the packages are not compiled the right way in order to make shared
> objects).
>
> Adrian
>
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_regex-mt.a(instances.o):
> relocation R_X86_64_32 against
> `boost::object_cache<boost::re_detail::cpp_regex_traits_base<char>,
> boost::re_detail::cpp_regex_traits_implementation<char>
>>::do_get(boost::re_detail::cpp_regex_traits_base<char> const&,
> unsigned long)::s_data' can not be used when making a shared object;
> recompile with -fPIC
> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_regex-mt.a:
> could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[2]: *** [Code/GraphMol/SLNParse/Wrap/rdSLNParse.so] Error 1
> make[1]: *** [Code/GraphMol/SLNParse/Wrap/CMakeFiles/rdSLNParse.dir/all] Error 2
> make: *** [all] Error 2

Yeah, that looks like the kubuntu boost-devel package has not been
correctly compiled. Is it possible to enter a bug on the kubuntu site?

-greg

[Rdkit-devel] Building RDKit on Lucid Lynx with distribution packages (x64)

[Adrian S. <am...@ca...>]

Hi Greg,

I just tried to compile RDKit on Kubuntu 10.04 amd64 with the
boost-devel packages that come with the distribution. Unfortunately it
failed, you might want to update the wiki (at least for 64-bit systems
the packages are not compiled the right way in order to make shared
objects).

Adrian

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_regex-mt.a(instances.o):
relocation R_X86_64_32 against
`boost::object_cache<boost::re_detail::cpp_regex_traits_base<char>,
boost::re_detail::cpp_regex_traits_implementation<char>
>::do_get(boost::re_detail::cpp_regex_traits_base<char> const&,
unsigned long)::s_data' can not be used when making a shared object;
recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_regex-mt.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [Code/GraphMol/SLNParse/Wrap/rdSLNParse.so] Error 1
make[1]: *** [Code/GraphMol/SLNParse/Wrap/CMakeFiles/rdSLNParse.dir/all] Error 2
make: *** [all] Error 2

[Rdkit-devel] Q1 2010 Release

[Greg L. <gre...@gm...>]

Dear all,

I'm very happy to announce that the next version of the RDKit --
Q12010_1 -- is released.

The release notes are below.

The source release and windows binaries (python 2.5 and 2.6) will be on
the sourceforge downloads page:
http://sourceforge.net/projects/rdkit/files/rdkit/Q1_2010/
The files can also be downloaded from the google project page:
http://code.google.com/p/rdkit/downloads/list

I will update the online documentation in the next week or so.

Thanks to the everyone who submitted bug reports and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one.

-greg

******  Release_Q12010_1 *******
(Changes relative to Release_Q42009_1)

Acknowledgements:
 - Andrew Dalke, Jean-Marc Nuzillard, Noel O'Boyle, Gianluca Sforna,
   Nik Stiefl, Anna Vulpetti

Bug Fixes
 - Substantial improvements were made to the SLN parser
 - A bad depiction case was fixed. (issue 2948402)
 - Hs added to planar carbons are no longer in the same plane as the
   other atoms. (issue 2951221)
 - Elements early in the periodic table (e.g. Mg, Na, etc.) no longer
   have their radical counts incorrectly assigned. (issue 2952255)
 - Some improvements were made to the v3k mol file parser. (issue
   2952272)
 - Double bonds with unspecified stereochemistry are now correctly
   flagged when output to mol files. (issue 2963522)
 - A segmentation fault that occured when kekulizing modified
   molecules has been fixed. (issue 2983794)

New Features
 - The MaxMin diversity picker can now be given a seed for the random
   number generator to ensure reproducible results.

Other
 - the vflib source, which is no longer used, was removed from the
   External source tree. It's still available in svn at rev1323 or via
   this tarball:
   http://rdkit.svn.sourceforge.net/viewvc/rdkit/trunk/External/vflib-2.0.tar.gz?view=tar&pathrev=1323
 - the directory Contrib has been added to the RDKit distribution to
   house contributions that don't necessarily fit anywhere else. The
   first contribution here is a collection of scripts required to
   implement local-environment fingerprints contributed by Anna
   Vulpetti.
 - Some optimization work was done on the molecule initialization code:
   reading in molecules is now somewhat faster.
 - Some optimization work was done on the RDK and Layered fingerprinting code.

[Rdkit-devel] beta of Q1 2010 release up

[Greg L. <gre...@gm...>]

Dear all,

I have tagged a beta of the Q1 2010 release in svn:
https://rdkit.svn.sourceforge.net/svnroot/rdkit/tags/Release_Q12010_1beta1
and uploaded a source distribution to the google code page for those
who don't want to deal with svn:
http://code.google.com/p/rdkit/downloads
Draft release notes are here:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_Q12010_1beta1/ReleaseNotes.txt?view=markup

If anyone is interested in testing Windows binary, let me know and I
will upload it as well.

As usual: if no problems come up in the next week I will go ahead and
do the actual release.

Best regards,
-greg

[Rdkit-devel] Q4 2009 Release

[Greg L. <gre...@gm...>]

I'm very happy to announce that the next version of the RDKit --
Q42009_1 -- is released.

The release notes are below.

The source release and windows binaries (python 2.5 and 2.6) will be on
the sourceforge downloads page:
http://sourceforge.net/projects/rdkit/files/rdkit/Q4_2009/
The files can also be downloaded from the google project page:
http://code.google.com/p/rdkit/downloads/list

I will update the online documentation this week.

Thanks to the everyone who submitted bug reports and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one.

-greg

******  Release_Q42009_1 *******
(Changes relative to Release_Q32009_1)

!!!!!! IMPORTANT !!!!!!
  - A bug fix in the SMARTS parser has changed the way atom-map
    numbers in Reaction SMARTS are parsed.
      Earlier versions of the RDKit required that atom maps be
      specified at the beginning of a complex atom query:
        [CH3:1,NH2]>>[*:1]O
      The corrected version only accepts this form:
        [CH3,NH2:1]>>[*:1]O
    This change may break existing SMARTS patterns.
  - A switch to using cmake as the build system instead of bjam has
    made the RDKit much easier to build.

Acknowledgements
  - Andrew Dalke, Kirk DeLisle, David Hall, Markus Kossner, Adrian
    Schreyer, Nikolaus Stiefl, Jeremy Yang

Bug Fixes
  - the SMARTS parser now correctly requires tha atom-map numbers be
    at the end of a complex atom query.
    (issue 1804420)
  - a bug in the way SMARTS matches are uniquified has been fixed
    (issue 2884178)

New Features
  - The new SMARTS atomic query feature "x" (number of ring bonds) is
    now supported.
  - The proof-of-concept for a SWIG-based wrapper around the RDKit has
    been expanded a bit in functionality. Samples are now included for
    Java, C#, and Python.
  - Information about the current RDKit and boost versions is now
    available from C++ (file RDGeneral/versions.h) and Python
    (rdBase.rdkitVersion and rdBase.boostVersion)
  - The KNN code now supports weighted nearest-neighbors calculations
    with a radius cutoff.

Other
  - The lapack dependency has been completely removed from the RDKit.
  - The supported build system for the RDKit is now cmake
    (http://www.cmake.org) instead of bjam. See the file INSTALL for
    the new installation instructions. Files for bjam are still
    included in the distribution but are deprecated and will be
    removed in a future version.

[Rdkit-devel] lapack dependency finally gone

[Greg L. <gre...@gm...>]

Dear all,

This morning I finally figured out how to get rid of the lapack
dependencies in the RDKit in a reasonable (and backwards compatible)
manner.

Lapack was being used to generate eigenvalues of the distance matrix
for molecules and fragments of molecules. These eigenvalues are used,
along with the Balaban J index, as invariants to distinguish molecular
subgraphs from each other in the Subgraphs and FragCatalog code. I've
replaced the invariant calculation completely and now use a hashing
approach with the Morgan algorithm similar to that used in the
MorganFingerprint code. The new, simpler, code is in
$RDBASE/Code/GraphMol/Subgraphs/SubgraphUtils.cpp. There's not much in
the way of documentation in the new code and it could definitely stand
to be cleaned up, but the big step is taken.

A particularly pleasant side effect of all this is that the
findUniqueSubgraphs family of functions are now substantially faster
(about a factor of three). The fragment catalog stuff should also be a
lot faster, but I haven't done the benchmarking there yet.

The last remaining lapack dependency is in the regression tests for
the power eigenvalue solver; I'll get rid of this in the next few
days, clean up the build system, and remove all traces of lapack from
the code; that's easy stuff.

This one has been nagging for a while... it's nice to have it done.

-greg

Re: [Rdkit-devel] Successful build with Kubuntu 9.10 x64

[Greg L. <gre...@gm...>]

Thanks Adrian. I put the info in the wiki.

Going to have to take a look at ubuntu 9.10 soon.
-greg


On Fri, Oct 30, 2009 at 11:49 AM, Adrian Schreyer <am...@ca...> wrote:
> Working build
>
> RDKit Version: Q3 2009
> OS: Kubuntu 9.10 x64 (virtual machine)
> Compiler: 4.4.1 (Ubuntu 4.4.1-4ubuntu8)
> Boost version: 1.40
> Python version: 2.6.4rc2
>
> I highly recommend upgrading from 9.04, especially for KDE users.
>
> Cheers,
>
> Adrian
>

[Rdkit-devel] Successful build with Kubuntu 9.10 x64

[Adrian S. <am...@ca...>]

Working build

RDKit Version: Q3 2009
OS: Kubuntu 9.10 x64 (virtual machine)
Compiler: 4.4.1 (Ubuntu 4.4.1-4ubuntu8)
Boost version: 1.40 	
Python version: 2.6.4rc2

I highly recommend upgrading from 9.04, especially for KDE users.

Cheers,

Adrian

Re: [Rdkit-devel] Compiling RDKit on CentOS 5.3 x64

[Adrian S. <am...@ca...>]

I should have mentioned that I used boost_1_39_0, not the latest
version. In addition, boost.jam is not available through yum and has
to be compiled manually.

On Fri, Oct 16, 2009 at 10:02, Greg Landrum <gre...@gm...> wrote:
> Hi Adrian,
>
> Thanks for the update. I saw the comment on the benchmarks page and
> updated that already, I'll put the information in the working build
> page as well.
>
> Thanks again,
> -greg
>
> On Fri, Oct 16, 2009 at 10:15 AM, Adrian Schreyer <am...@ca...> wrote:
>> Thanks, that worked. Maybe you can add this to the WorkingBuild wiki page.
>>
>> Here are the results from the benchmark on my machine (Intel i7 920 /
>> CentOS 5.3 x64 (on vmware with 2 cores and 2gb memory) / g++
>> 4.1.2-44)) :
>>
>> times:  1.3 || 0.8 || 0.4 || 1.9 || 2.1 || 0.0 || 5.9 || 6.0 || 0.4 ||
>> 0.6 || 15.4 || 0.5 || 7.5
>>
>

Re: [Rdkit-devel] Compiling RDKit on CentOS 5.3 x64

[Greg L. <gre...@gm...>]

Hi Adrian,

Thanks for the update. I saw the comment on the benchmarks page and
updated that already, I'll put the information in the working build
page as well.

Thanks again,
-greg

On Fri, Oct 16, 2009 at 10:15 AM, Adrian Schreyer <am...@ca...> wrote:
> Thanks, that worked. Maybe you can add this to the WorkingBuild wiki page.
>
> Here are the results from the benchmark on my machine (Intel i7 920 /
> CentOS 5.3 x64 (on vmware with 2 cores and 2gb memory) / g++
> 4.1.2-44)) :
>
> times:  1.3 || 0.8 || 0.4 || 1.9 || 2.1 || 0.0 || 5.9 || 6.0 || 0.4 ||
> 0.6 || 15.4 || 0.5 || 7.5
>

Re: [Rdkit-devel] Compiling RDKit on CentOS 5.3 x64

[Adrian S. <am...@ca...>]

Thanks, that worked. Maybe you can add this to the WorkingBuild wiki page.

Here are the results from the benchmark on my machine (Intel i7 920 /
CentOS 5.3 x64 (on vmware with 2 cores and 2gb memory) / g++
4.1.2-44)) :

times:  1.3 || 0.8 || 0.4 || 1.9 || 2.1 || 0.0 || 5.9 || 6.0 || 0.4 ||
0.6 || 15.4 || 0.5 || 7.5

Adrian

On Fri, Oct 16, 2009 at 05:23, Greg Landrum <gre...@gm...> wrote:
> Hi Adrian,
>
> The problem below should be solvable by adding a compile flag.
> Please try adding:
> <toolset>gcc:<cflags>-DBOOST_PYTHON_NO_PY_SIGNATURES
> to $RDBASE/Code/Jamroot
>
> There's some information here:
> https://sourceforge.net/mailarchive/message.php?msg_name=60825b0f0901152045i20eff2p427119822d8c2518%40mail.gmail.com
>
> Best regards,
> -greg
>
> On Thu, Oct 15, 2009 at 8:39 PM, Adrian Schreyer <am...@ca...> wrote:
>> Hi Greg,
>>
>> I tried to compile RDKit on CentOS 5.3 64 bit but for one target I get
>> a cryptic error.  The bjam output is attached. Any suggestions?
>>
>> Adrian
>>
>> ----
>> gcc -v
>> Using built-in specs.
>> Target: x86_64-redhat-linux
>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
>> --infodir=/usr/share/info --enable-shared --enable-threads=posix
>> --enable-checking=release --with-system-zlib --enable-__cxa_atexit
>> --disable-libunwind-exceptions --enable-libgcj-multifile
>> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
>> --enable-java-awt=gtk --disable-dssi --enable-plugin
>> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
>> --with-cpu=generic --host=x86_64-redhat-linux
>> Thread model: posix
>> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
>>
>

Re: [Rdkit-devel] Compiling RDKit on CentOS 5.3 x64

[Greg L. <gre...@gm...>]

Hi Adrian,

The problem below should be solvable by adding a compile flag.
Please try adding:
<toolset>gcc:<cflags>-DBOOST_PYTHON_NO_PY_SIGNATURES
to $RDBASE/Code/Jamroot

There's some information here:
https://sourceforge.net/mailarchive/message.php?msg_name=60825b0f0901152045i20eff2p427119822d8c2518%40mail.gmail.com

Best regards,
-greg

On Thu, Oct 15, 2009 at 8:39 PM, Adrian Schreyer <am...@ca...> wrote:
> Hi Greg,
>
> I tried to compile RDKit on CentOS 5.3 64 bit but for one target I get
> a cryptic error.  The bjam output is attached. Any suggestions?
>
> Adrian
>
> ----
> gcc -v
> Using built-in specs.
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --enable-checking=release --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-libgcj-multifile
> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
> --enable-java-awt=gtk --disable-dssi --enable-plugin
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> --with-cpu=generic --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
>

[Rdkit-devel] Compiling RDKit on CentOS 5.3 x64

[Adrian S. <am...@ca...>]

Hi Greg,

I tried to compile RDKit on CentOS 5.3 64 bit but for one target I get
a cryptic error.  The bjam output is attached. Any suggestions?

Adrian

----
gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)

Re: [Rdkit-devel] CMake_28Sept2009 pull BLAS and LAPACK

[Greg L. <gre...@gm...>]

Riccardo,

Well, it took longer than I hoped, but it looks like things now more
or less work on windows, linux, and the Mac (rev1237).

I had to make a fair number of modifications due to the static linking
on windows, and it might be worth going back at some point and
cleaning things up, but what's there now seems to be functional.

Let me know what you think.

-greg

Re: [Rdkit-devel] CMake_28Sept2009 pull BLAS and LAPACK

[Greg L. <gre...@gm...>]

On Fri, Oct 2, 2009 at 1:05 AM, Riccardo Vianello
<ric...@gm...> wrote:
>
>> I had to make a fair number of modifications due to the static linking
>> on windows, and it might be worth going back at some point and
>> cleaning things up, but what's there now seems to be functional.
>>
>> Let me know what you think.
>
> it's been a busy day and unfortunately I only had time for a quick
> tour.. in browsing a sample of the involved files, I had the
> impression that modifying almost every cmake listfile was most often
> required by making link-time dependencies explicit again, is that
> correct? There are of course other changes here and there, but they
> seem more localized and involve a more limited number of files...

Yes, the changes are almost all adding libraries that the various
regressions and python modules need to be linked against. The changes
end up being massively redundant, since for example linking against
GraphMol also requires RDGeneral and RDGeometryLib, but the
information does need to be provided.

I guess one possibility to make life easier would be to modify
rdkit_library so that it defines a new variable containing the new
library name along with that libraries dependencies and then using
those new variables for regressions. So something like:

rdkit_library(GraphMol
              Atom.cpp <clipped for clarity> Conformer.cpp
              LINK_LIBRARIES RDGeometryLib RDGeneral )

would define the new variable GraphMol_LIBS (or some such thing) that
could be used to replace:

rdkit_test(graphmolTest1 test1.cpp LINK_LIBRARIES GraphMol
RDGeometryLib RDGeneral)

with:

rdkit_test(graphmolTest1 test1.cpp LINK_LIBRARIES GraphMol_LIBS)

This would probably lead to a lot of redundancy for cmake to deal
with, since something like:

rdkit_test(graphmoltestCanon testCanon.cpp
           LINK_LIBRARIES SubstructMatch_LIBS SmilesParse_LIBS GraphMol_LIBS)

is going to expand to:

rdkit_test(graphmoltestCanon testCanon.cpp
           LINK_LIBRARIES SubstructMatch GraphMol RDGeometryLib
RDGeneral SmilesParse GraphMol RDGeometryLib RDGeneral  GraphMol
GraphMol RDGeometryLib RDGeneral )

but I would hope that cmake could deal with that.

What do you think?

-greg



>
> I hope to be able to provide a better feedback tomorrow..
>
> --
> Ric
>

Re: [Rdkit-devel] CMake_28Sept2009 pull BLAS and LAPACK

[Riccardo V. <ric...@gm...>]

Hi,

> I had to make a fair number of modifications due to the static linking
> on windows, and it might be worth going back at some point and
> cleaning things up, but what's there now seems to be functional.
>
> Let me know what you think.

it's been a busy day and unfortunately I only had time for a quick
tour.. in browsing a sample of the involved files, I had the
impression that modifying almost every cmake listfile was most often
required by making link-time dependencies explicit again, is that
correct? There are of course other changes here and there, but they
seem more localized and involve a more limited number of files...

I hope to be able to provide a better feedback tomorrow..

-- 
Ric