Re: [Rdkit-discuss] RDKit build issues

[Greg Landrum]

Yeah, please send me (no reason to send them to the whole list) the ctest
-V logs from running those failing tests individually and we'll see if we
can figure this out.

-greg


On Tue, Apr 19, 2016 at 10:26 PM, Matthew Lardy  wrote:

>
> I've been doing that too, and I am very happy that I've got the Java
> wrappers built (v2016.03.1).  I've got four Python operations that fail.  I
> can send the log from ctest -V if you'd like:
>
> 97% tests passed, 4 tests failed out of 133
>
> Total Test time (real) = 464.59 sec
>
> The following tests FAILED:
>  44 - pyChemReactions (Failed)
>  62 - pyForceFieldHelpers (Failed)
>  86 - pyGraphMolWrap (Failed)
> 133 - pythonTestDirChem (Failed)
> Errors while running CTest
>
> Thanks for everyone's help!
> Matt
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] RDKit build issues

[Matthew Lardy]

Hi Greg,

I've been doing that too, and I am very happy that I've got the Java
wrappers built (v2016.03.1).  I've got four Python operations that fail.  I
can send the log from ctest -V if you'd like:

97% tests passed, 4 tests failed out of 133

Total Test time (real) = 464.59 sec

The following tests FAILED:
 44 - pyChemReactions (Failed)
 62 - pyForceFieldHelpers (Failed)
 86 - pyGraphMolWrap (Failed)
133 - pythonTestDirChem (Failed)
Errors while running CTest

Thanks for everyone's help!
Matt


On Tue, Apr 19, 2016 at 4:23 AM, Greg Landrum 
wrote:

> It's great that you're almost there.
>
> The best way to help diagnose problems running the tests is to run ctest
> in verbose mode with "-V". Here's an example on my machine:
>
> glandrum@Otter:/scratch/RDKit_git/build$ echo $RDBASE
> /scratch/RDKit_git
> glandrum@Otter:/scratch/RDKit_git/build$ echo $LD_LIBRARY_PATH
> /scratch/RDKit_git/lib:/usr/local/pgsql/lib:
> glandrum@Otter:/scratch/RDKit_git/build$ ctest -V -R JavaAromat
> UpdateCTestConfiguration  from
> :/scratch/RDKit_git/build/DartConfiguration.tcl
> UpdateCTestConfiguration  from
> :/scratch/RDKit_git/build/DartConfiguration.tcl
> Test project /scratch/RDKit_git/build
> Constructing a list of tests
> Done constructing a list of tests
> Checking test dependency graph...
> Checking test dependency graph end
> test 99
> Start 99: JavaAromaticTests
>
> 99: Test command: /usr/bin/java
> "-Djava.library.path=/scratch/RDKit_git/Code/JavaWrappers/gmwrapper" "-cp"
> "/scratch/RDKit_git/External/java_lib/junit.jar:/scratch/RDKit_git/Code/JavaWrappers/gmwrapper/build-test:/scratch/RDKit_git/Code/JavaWrappers/gmwrapper/org.RDKit.jar"
> "org.RDKit.AromaticTests"
> 99: Test timeout computed to be: 9.99988e+06
> 99: JUnit version 4.10
> 99: ..
> 99: Time: 1.8
> 99:
> 99: OK (2 tests)
> 99:
> 1/1 Test #99: JavaAromaticTests    Passed1.99 sec
>
> The following tests passed:
> JavaAromaticTests
>
> 100% tests passed, 0 tests failed out of 1
>
> Total Test time (real) =   2.00 sec
> glandrum@Otter:/scratch/RDKit_git/build$
>
>
> I do not have CLASSPATH set and I don't think it's necessary in order to
> be able to run the tests.
>
> -greg
>
>
>
>
> On Mon, Apr 18, 2016 at 11:47 PM, Matthew Lardy  wrote:
>
>> Hi Brian,
>>
>> Thanks!  I gave it a whirl, but no improvement.  In previous installs
>> I've specified the shared object directly, but there isn't a good reason
>> for me to do so.  I've done a make install, so everything should be built
>> wherever it is supposed to go.
>>
>> I've missed something simple.  I just don't see it yet,
>> Matt
>>
>>
>> On Mon, Apr 18, 2016 at 2:08 PM, Brian Kelley 
>> wrote:
>>
>>> > $RDBASE/Code/JavaWrappers/gmwrapper/libGraphMolWrap.so
>>>
>>> You probably need to drop the explicit .so, the library path is the path
>>> to the directory not to the .so itself.
>>>
>>> Here is what I normally use for testing ( note I usually build into an
>>> rdkit_build directory via:   -DCMAKE_INSTALL_PREFIX=>> rdkit_build> )
>>>
>>>
>>> RDBASE=`pwd`/../../rdkit LD_LIBRARY_PATH=`pwd`/rdkit_build/lib
>>> PYTHONPATH=`pwd`/rdkit_build/lib/python2.7/site-packages ctest
>>>
>>> On Mon, Apr 18, 2016 at 4:57 PM, Matthew Lardy  wrote:
>>>
 A quick question, what should be set up for the environment for the
 Java wrappers?  I've got the following set:

 setenv RDBASE $WORKSPACE/RDKit-2016/rdkit-Release_2016_03
 setenv PATH ${PATH}:$RDBASE/lib

 setenv CLASSPATH $RDBASE/Code/JavaWrappers/gmwrapper/org.RDKit.jar
 setenv LD_LIBRARY_PATH
 ${LD_LIBRARY_PATH}:$WORKSPACE/boost1.59/lib:$RDBASE/build/lib:$RDBASE/Code/JavaWrappers/gmwrapper/libGraphMolWrap.so
 setenv PYTHONPATH ${PYTHONPATH}:$RDBASE

 The code builds without issue, save a few warnings.  Here is the Java
 error I am getting (during the tests):

 JUnit version 4.12
 119: Exception in thread "main" java.lang.NoClassDefFoundError:
 org/hamcrest/SelfDescribing

 Is my CLASSPATH wrong?  Did I forget a SO in my LD_LIBRARY_PATH?

 Thanks in advance!
 Matt



 On Mon, Apr 18, 2016 at 9:56 AM, Matthew Lardy 
 wrote:

> My thoughts exactly.  I've forgotten to set RDBASE before and had a
> few tests fail.  This is different.  It was everything and it took me days
> to get to a place where some of the base code was passing tests.  Someone
> mentioned that I need to build boost with the version of Python that I am
> using.  This is problem in an environment where people choose their own
> adventure with modules.  I have no guarantee that they won't chose Python
> 3.x when I've compiled everything with 2.7.7.  That problem will be a good
> to have when I get there.  :)
>
> If my present build doesn't pass everything, and it won't, I'll send
> you the fun 

Re: [Rdkit-discuss] RDKit build issues

[Matthew Lardy]

Hi Brian,

Thanks!  I gave it a whirl, but no improvement.  In previous installs I've
specified the shared object directly, but there isn't a good reason for me
to do so.  I've done a make install, so everything should be built wherever
it is supposed to go.

I've missed something simple.  I just don't see it yet,
Matt


On Mon, Apr 18, 2016 at 2:08 PM, Brian Kelley  wrote:

> > $RDBASE/Code/JavaWrappers/gmwrapper/libGraphMolWrap.so
>
> You probably need to drop the explicit .so, the library path is the path
> to the directory not to the .so itself.
>
> Here is what I normally use for testing ( note I usually build into an
> rdkit_build directory via:   -DCMAKE_INSTALL_PREFIX=
> )
>
>
> RDBASE=`pwd`/../../rdkit LD_LIBRARY_PATH=`pwd`/rdkit_build/lib
> PYTHONPATH=`pwd`/rdkit_build/lib/python2.7/site-packages ctest
>
> On Mon, Apr 18, 2016 at 4:57 PM, Matthew Lardy  wrote:
>
>> A quick question, what should be set up for the environment for the Java
>> wrappers?  I've got the following set:
>>
>> setenv RDBASE $WORKSPACE/RDKit-2016/rdkit-Release_2016_03
>> setenv PATH ${PATH}:$RDBASE/lib
>>
>> setenv CLASSPATH $RDBASE/Code/JavaWrappers/gmwrapper/org.RDKit.jar
>> setenv LD_LIBRARY_PATH
>> ${LD_LIBRARY_PATH}:$WORKSPACE/boost1.59/lib:$RDBASE/build/lib:$RDBASE/Code/JavaWrappers/gmwrapper/libGraphMolWrap.so
>> setenv PYTHONPATH ${PYTHONPATH}:$RDBASE
>>
>> The code builds without issue, save a few warnings.  Here is the Java
>> error I am getting (during the tests):
>>
>> JUnit version 4.12
>> 119: Exception in thread "main" java.lang.NoClassDefFoundError:
>> org/hamcrest/SelfDescribing
>>
>> Is my CLASSPATH wrong?  Did I forget a SO in my LD_LIBRARY_PATH?
>>
>> Thanks in advance!
>> Matt
>>
>>
>>
>> On Mon, Apr 18, 2016 at 9:56 AM, Matthew Lardy  wrote:
>>
>>> My thoughts exactly.  I've forgotten to set RDBASE before and had a few
>>> tests fail.  This is different.  It was everything and it took me days to
>>> get to a place where some of the base code was passing tests.  Someone
>>> mentioned that I need to build boost with the version of Python that I am
>>> using.  This is problem in an environment where people choose their own
>>> adventure with modules.  I have no guarantee that they won't chose Python
>>> 3.x when I've compiled everything with 2.7.7.  That problem will be a good
>>> to have when I get there.  :)
>>>
>>> If my present build doesn't pass everything, and it won't, I'll send you
>>> the fun directly.  :)
>>>
>>> Thanks again Greg!
>>> Matt
>>>
>>>
>>> On Fri, Apr 15, 2016 at 9:34 PM, Greg Landrum 
>>> wrote:
>>>
 Brian's suggestion to take a look at the cmake invocation in the travis
 file is a good one.

 Based on the number of failing tests, I think something more than just
 an RDBASE problem is wrong. The best way to track this down is by sending
 me the cmake command you ran, the output of running make, and the output of
 running ctest (after you run ctest you will find this in the directory
 Testing/Temporary/LastTest.log). Because this is pretty large and likely
 not of interest to others, it's probably best to send it directly to me or
 to create a gist and send the link to that.

 -greg



 On Sat, Apr 16, 2016 at 2:22 AM, Brian Kelley 
 wrote:

> Getting the right version of boost can be tricky.  You can see our
> normal cmake incantation here as well as how we set RDBASE for tests
>
> https://github.com/rdkit/rdkit/blob/master/.travis.yml
>
> Note the
>
> -D Boost_NO_SYSTEM_PATHS=ON
>
> When running cmake, otherwise cmake can get very confused.
>
>
> 
> Brian Kelley
>
> On Apr 15, 2016, at 6:26 PM, Matthew Lardy  wrote:
>
> I'll add, that remembering that cmake and ccmake can produce different
> outcomes I've gone back to trying cmake.  But I can't overwrite the
> variables in cmake.  Here are the results from trying to specify them:
>
>  Manually-specified variables were not used by the project:
>
> BOOST_DIR
> BOOST_INCLUDE_DIR
> BOOST_LIBRARY_DIR
> BOOST_PYTHON_LIBRARY_DEBUG
> BOOST_PYTHON_LIBRARY_RELEASE
> BOOST_REGEX_LIBRARY_DEBUG
> BOOST_REGEX_LIBRARY_RELEASE
> BOOST_SERIALIZATION_LIBRARY_DEBUG
> BOOST_SERIALIZATION_LIBRARY_RELEASE
> BOOST_SYSTEM_LIBRARY_DEBUG
> BOOST_SYSTEM_LIBRARY_RELEASE
> BOOST_THREAD_LIBRARY_DEBUG
> BOOST_THREAD_LIBRARY_RELEASE
>
> cmake, as per it's usual, picked up an ancient version of boost (which
> I want to override).  I can get around this with ccmake, but nothing that 
> I
> compile can pass all of the tests.  If someone knows what these variables
> (shown in ccmake) are called, I'd love to know.
>
> Thanks in advance!
> 

Re: [Rdkit-discuss] RDKit build issues

[Matthew Lardy]

A quick question, what should be set up for the environment for the Java
wrappers?  I've got the following set:

setenv RDBASE $WORKSPACE/RDKit-2016/rdkit-Release_2016_03
setenv PATH ${PATH}:$RDBASE/lib

setenv CLASSPATH $RDBASE/Code/JavaWrappers/gmwrapper/org.RDKit.jar
setenv LD_LIBRARY_PATH
${LD_LIBRARY_PATH}:$WORKSPACE/boost1.59/lib:$RDBASE/build/lib:$RDBASE/Code/JavaWrappers/gmwrapper/libGraphMolWrap.so
setenv PYTHONPATH ${PYTHONPATH}:$RDBASE

The code builds without issue, save a few warnings.  Here is the Java error
I am getting (during the tests):

JUnit version 4.12
119: Exception in thread "main" java.lang.NoClassDefFoundError:
org/hamcrest/SelfDescribing

Is my CLASSPATH wrong?  Did I forget a SO in my LD_LIBRARY_PATH?

Thanks in advance!
Matt



On Mon, Apr 18, 2016 at 9:56 AM, Matthew Lardy  wrote:

> My thoughts exactly.  I've forgotten to set RDBASE before and had a few
> tests fail.  This is different.  It was everything and it took me days to
> get to a place where some of the base code was passing tests.  Someone
> mentioned that I need to build boost with the version of Python that I am
> using.  This is problem in an environment where people choose their own
> adventure with modules.  I have no guarantee that they won't chose Python
> 3.x when I've compiled everything with 2.7.7.  That problem will be a good
> to have when I get there.  :)
>
> If my present build doesn't pass everything, and it won't, I'll send you
> the fun directly.  :)
>
> Thanks again Greg!
> Matt
>
>
> On Fri, Apr 15, 2016 at 9:34 PM, Greg Landrum 
> wrote:
>
>> Brian's suggestion to take a look at the cmake invocation in the travis
>> file is a good one.
>>
>> Based on the number of failing tests, I think something more than just an
>> RDBASE problem is wrong. The best way to track this down is by sending me
>> the cmake command you ran, the output of running make, and the output of
>> running ctest (after you run ctest you will find this in the directory
>> Testing/Temporary/LastTest.log). Because this is pretty large and likely
>> not of interest to others, it's probably best to send it directly to me or
>> to create a gist and send the link to that.
>>
>> -greg
>>
>>
>>
>> On Sat, Apr 16, 2016 at 2:22 AM, Brian Kelley 
>> wrote:
>>
>>> Getting the right version of boost can be tricky.  You can see our
>>> normal cmake incantation here as well as how we set RDBASE for tests
>>>
>>> https://github.com/rdkit/rdkit/blob/master/.travis.yml
>>>
>>> Note the
>>>
>>> -D Boost_NO_SYSTEM_PATHS=ON
>>>
>>> When running cmake, otherwise cmake can get very confused.
>>>
>>>
>>> 
>>> Brian Kelley
>>>
>>> On Apr 15, 2016, at 6:26 PM, Matthew Lardy  wrote:
>>>
>>> I'll add, that remembering that cmake and ccmake can produce different
>>> outcomes I've gone back to trying cmake.  But I can't overwrite the
>>> variables in cmake.  Here are the results from trying to specify them:
>>>
>>>  Manually-specified variables were not used by the project:
>>>
>>> BOOST_DIR
>>> BOOST_INCLUDE_DIR
>>> BOOST_LIBRARY_DIR
>>> BOOST_PYTHON_LIBRARY_DEBUG
>>> BOOST_PYTHON_LIBRARY_RELEASE
>>> BOOST_REGEX_LIBRARY_DEBUG
>>> BOOST_REGEX_LIBRARY_RELEASE
>>> BOOST_SERIALIZATION_LIBRARY_DEBUG
>>> BOOST_SERIALIZATION_LIBRARY_RELEASE
>>> BOOST_SYSTEM_LIBRARY_DEBUG
>>> BOOST_SYSTEM_LIBRARY_RELEASE
>>> BOOST_THREAD_LIBRARY_DEBUG
>>> BOOST_THREAD_LIBRARY_RELEASE
>>>
>>> cmake, as per it's usual, picked up an ancient version of boost (which I
>>> want to override).  I can get around this with ccmake, but nothing that I
>>> compile can pass all of the tests.  If someone knows what these variables
>>> (shown in ccmake) are called, I'd love to know.
>>>
>>> Thanks in advance!
>>> Matthew
>>>
>>>
>>> On Fri, Apr 15, 2016 at 2:58 PM, Matthew Lardy  wrote:
>>>
 Hi all,

 If someone has an insight I would love to hear it about how best to
 build RDKit from scratch.

 I am using the following to build the 2015.03 release:
 RedHat Linux version 6.4
 gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
 swig version 3.0.8
 cmake version 3.0.0
 boost version 1.53.0 (I've also tried boost 1.59.0)
 python version 2.7.7

 I use ccmake and alter the things which need to be altered (as cmake
 always grabs the wrong things for me).  My build compiles nicely, and
 without errors.  But the tests are a mess.  Here is the summary of my 
 build:

 26% tests passed, 87 tests failed out of 118

 I've put the details of the tests, in the hope that someone sees a
 pattern that I do not, below.

 Before someone recommends a clean install that is not possible.  I also
 do not have root, so I can't just wipe the machine and start over.  I
 cannot use an RPM, so that is out too.  Any ideas are welcome!

 Thanks,
 Matthew

Re: [Rdkit-discuss] RDKit build issues

[Matthew Lardy]

My thoughts exactly.  I've forgotten to set RDBASE before and had a few
tests fail.  This is different.  It was everything and it took me days to
get to a place where some of the base code was passing tests.  Someone
mentioned that I need to build boost with the version of Python that I am
using.  This is problem in an environment where people choose their own
adventure with modules.  I have no guarantee that they won't chose Python
3.x when I've compiled everything with 2.7.7.  That problem will be a good
to have when I get there.  :)

If my present build doesn't pass everything, and it won't, I'll send you
the fun directly.  :)

Thanks again Greg!
Matt


On Fri, Apr 15, 2016 at 9:34 PM, Greg Landrum 
wrote:

> Brian's suggestion to take a look at the cmake invocation in the travis
> file is a good one.
>
> Based on the number of failing tests, I think something more than just an
> RDBASE problem is wrong. The best way to track this down is by sending me
> the cmake command you ran, the output of running make, and the output of
> running ctest (after you run ctest you will find this in the directory
> Testing/Temporary/LastTest.log). Because this is pretty large and likely
> not of interest to others, it's probably best to send it directly to me or
> to create a gist and send the link to that.
>
> -greg
>
>
>
> On Sat, Apr 16, 2016 at 2:22 AM, Brian Kelley 
> wrote:
>
>> Getting the right version of boost can be tricky.  You can see our normal
>> cmake incantation here as well as how we set RDBASE for tests
>>
>> https://github.com/rdkit/rdkit/blob/master/.travis.yml
>>
>> Note the
>>
>> -D Boost_NO_SYSTEM_PATHS=ON
>>
>> When running cmake, otherwise cmake can get very confused.
>>
>>
>> 
>> Brian Kelley
>>
>> On Apr 15, 2016, at 6:26 PM, Matthew Lardy  wrote:
>>
>> I'll add, that remembering that cmake and ccmake can produce different
>> outcomes I've gone back to trying cmake.  But I can't overwrite the
>> variables in cmake.  Here are the results from trying to specify them:
>>
>>  Manually-specified variables were not used by the project:
>>
>> BOOST_DIR
>> BOOST_INCLUDE_DIR
>> BOOST_LIBRARY_DIR
>> BOOST_PYTHON_LIBRARY_DEBUG
>> BOOST_PYTHON_LIBRARY_RELEASE
>> BOOST_REGEX_LIBRARY_DEBUG
>> BOOST_REGEX_LIBRARY_RELEASE
>> BOOST_SERIALIZATION_LIBRARY_DEBUG
>> BOOST_SERIALIZATION_LIBRARY_RELEASE
>> BOOST_SYSTEM_LIBRARY_DEBUG
>> BOOST_SYSTEM_LIBRARY_RELEASE
>> BOOST_THREAD_LIBRARY_DEBUG
>> BOOST_THREAD_LIBRARY_RELEASE
>>
>> cmake, as per it's usual, picked up an ancient version of boost (which I
>> want to override).  I can get around this with ccmake, but nothing that I
>> compile can pass all of the tests.  If someone knows what these variables
>> (shown in ccmake) are called, I'd love to know.
>>
>> Thanks in advance!
>> Matthew
>>
>>
>> On Fri, Apr 15, 2016 at 2:58 PM, Matthew Lardy  wrote:
>>
>>> Hi all,
>>>
>>> If someone has an insight I would love to hear it about how best to
>>> build RDKit from scratch.
>>>
>>> I am using the following to build the 2015.03 release:
>>> RedHat Linux version 6.4
>>> gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
>>> swig version 3.0.8
>>> cmake version 3.0.0
>>> boost version 1.53.0 (I've also tried boost 1.59.0)
>>> python version 2.7.7
>>>
>>> I use ccmake and alter the things which need to be altered (as cmake
>>> always grabs the wrong things for me).  My build compiles nicely, and
>>> without errors.  But the tests are a mess.  Here is the summary of my build:
>>>
>>> 26% tests passed, 87 tests failed out of 118
>>>
>>> I've put the details of the tests, in the hope that someone sees a
>>> pattern that I do not, below.
>>>
>>> Before someone recommends a clean install that is not possible.  I also
>>> do not have root, so I can't just wipe the machine and start over.  I
>>> cannot use an RPM, so that is out too.  Any ideas are welcome!
>>>
>>> Thanks,
>>> Matthew
>>>
>>> The following tests FAILED:
>>>   2 - testDataStructs (OTHER_FAULT)
>>>   3 - pyBV (Failed)
>>>   4 - pyDiscreteValueVect (Failed)
>>>   5 - pySparseIntVect (Failed)
>>>   7 - testGrid (OTHER_FAULT)
>>>   8 - testPyGeometry (Failed)
>>>  11 - pyAlignment (Failed)
>>>  14 - testMMFFForceField (OTHER_FAULT)
>>>  15 - pyForceFieldConstraints (Failed)
>>>  17 - pyDistGeom (Failed)
>>>  18 - graphmolTest1 (OTHER_FAULT)
>>>  21 - graphmolMolOpsTest (SEGFAULT)
>>>  23 - graphmoltestChirality (OTHER_FAULT)
>>>  24 - graphmoltestPickler (OTHER_FAULT)
>>>  26 - hanoiTest (OTHER_FAULT)
>>>  28 - testDepictor (OTHER_FAULT)
>>>  29 - pyDepictor (Failed)
>>>  32 - fileParsersTest1 (OTHER_FAULT)
>>>  33 - testMolSupplier (OTHER_FAULT)
>>>  34 - testMolWriter (OTHER_FAULT)
>>>  35 - testTplParser 

Re: [Rdkit-discuss] RDKit build issues

[Matthew Lardy]

Hi Brian,

The RDBASE was pointed out to me by others as well.  It appears that
rebuilding with cmake and forcing things via the command-line is working
out better than it did earlier.  I'm now up to just the python things
failing (although I haven't attempted to build the Java wrappers yet).

I am, clearly, all thumbs with cmake if things don't go well.  :)  Worse is
that in my environment nothing is stock.  In fact, I have to go back and
rebuild boost as it also found the ancient libraries that it shouldn't be
touching.

The C++ code is compiling and passing tests now.  No more failures!  Thank
you all!!
Matt






On Fri, Apr 15, 2016 at 5:22 PM, Brian Kelley  wrote:

> Getting the right version of boost can be tricky.  You can see our normal
> cmake incantation here as well as how we set RDBASE for tests
>
> https://github.com/rdkit/rdkit/blob/master/.travis.yml
>
> Note the
>
> -D Boost_NO_SYSTEM_PATHS=ON
>
> When running cmake, otherwise cmake can get very confused.
>
>
> 
> Brian Kelley
>
> On Apr 15, 2016, at 6:26 PM, Matthew Lardy  wrote:
>
> I'll add, that remembering that cmake and ccmake can produce different
> outcomes I've gone back to trying cmake.  But I can't overwrite the
> variables in cmake.  Here are the results from trying to specify them:
>
>  Manually-specified variables were not used by the project:
>
> BOOST_DIR
> BOOST_INCLUDE_DIR
> BOOST_LIBRARY_DIR
> BOOST_PYTHON_LIBRARY_DEBUG
> BOOST_PYTHON_LIBRARY_RELEASE
> BOOST_REGEX_LIBRARY_DEBUG
> BOOST_REGEX_LIBRARY_RELEASE
> BOOST_SERIALIZATION_LIBRARY_DEBUG
> BOOST_SERIALIZATION_LIBRARY_RELEASE
> BOOST_SYSTEM_LIBRARY_DEBUG
> BOOST_SYSTEM_LIBRARY_RELEASE
> BOOST_THREAD_LIBRARY_DEBUG
> BOOST_THREAD_LIBRARY_RELEASE
>
> cmake, as per it's usual, picked up an ancient version of boost (which I
> want to override).  I can get around this with ccmake, but nothing that I
> compile can pass all of the tests.  If someone knows what these variables
> (shown in ccmake) are called, I'd love to know.
>
> Thanks in advance!
> Matthew
>
>
> On Fri, Apr 15, 2016 at 2:58 PM, Matthew Lardy  wrote:
>
>> Hi all,
>>
>> If someone has an insight I would love to hear it about how best to build
>> RDKit from scratch.
>>
>> I am using the following to build the 2015.03 release:
>> RedHat Linux version 6.4
>> gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
>> swig version 3.0.8
>> cmake version 3.0.0
>> boost version 1.53.0 (I've also tried boost 1.59.0)
>> python version 2.7.7
>>
>> I use ccmake and alter the things which need to be altered (as cmake
>> always grabs the wrong things for me).  My build compiles nicely, and
>> without errors.  But the tests are a mess.  Here is the summary of my build:
>>
>> 26% tests passed, 87 tests failed out of 118
>>
>> I've put the details of the tests, in the hope that someone sees a
>> pattern that I do not, below.
>>
>> Before someone recommends a clean install that is not possible.  I also
>> do not have root, so I can't just wipe the machine and start over.  I
>> cannot use an RPM, so that is out too.  Any ideas are welcome!
>>
>> Thanks,
>> Matthew
>>
>> The following tests FAILED:
>>   2 - testDataStructs (OTHER_FAULT)
>>   3 - pyBV (Failed)
>>   4 - pyDiscreteValueVect (Failed)
>>   5 - pySparseIntVect (Failed)
>>   7 - testGrid (OTHER_FAULT)
>>   8 - testPyGeometry (Failed)
>>  11 - pyAlignment (Failed)
>>  14 - testMMFFForceField (OTHER_FAULT)
>>  15 - pyForceFieldConstraints (Failed)
>>  17 - pyDistGeom (Failed)
>>  18 - graphmolTest1 (OTHER_FAULT)
>>  21 - graphmolMolOpsTest (SEGFAULT)
>>  23 - graphmoltestChirality (OTHER_FAULT)
>>  24 - graphmoltestPickler (OTHER_FAULT)
>>  26 - hanoiTest (OTHER_FAULT)
>>  28 - testDepictor (OTHER_FAULT)
>>  29 - pyDepictor (Failed)
>>  32 - fileParsersTest1 (OTHER_FAULT)
>>  33 - testMolSupplier (OTHER_FAULT)
>>  34 - testMolWriter (OTHER_FAULT)
>>  35 - testTplParser (OTHER_FAULT)
>>  36 - testMol2ToMol (OTHER_FAULT)
>>  38 - testReaction (OTHER_FAULT)
>>  40 - pyChemReactions (Failed)
>>  41 - testChemTransforms (OTHER_FAULT)
>>  44 - testFragCatalog (OTHER_FAULT)
>>  45 - pyFragCatalog (Failed)
>>  46 - testDescriptors (OTHER_FAULT)
>>  47 - pyMolDescriptors (Failed)
>>  48 - testFingerprints (OTHER_FAULT)
>>  50 - pyPartialCharges (Failed)
>>  51 - testMolTransforms (OTHER_FAULT)
>>  52 - pyMolTransforms (Failed)
>>  53 - testMMFFForceFieldHelpers (OTHER_FAULT)
>>  54 - testUFFForceFieldHelpers (OTHER_FAULT)
>>  55 - pyForceFieldHelpers (Failed)
>>  56 - testDistGeomHelpers (OTHER_FAULT)
>>  57 - pyDistGeom (Failed)
>>  58 - testMolAlign 

Re: [Rdkit-discuss] RDKit build issues

[Greg Landrum]

Brian's suggestion to take a look at the cmake invocation in the travis
file is a good one.

Based on the number of failing tests, I think something more than just an
RDBASE problem is wrong. The best way to track this down is by sending me
the cmake command you ran, the output of running make, and the output of
running ctest (after you run ctest you will find this in the directory
Testing/Temporary/LastTest.log). Because this is pretty large and likely
not of interest to others, it's probably best to send it directly to me or
to create a gist and send the link to that.

-greg



On Sat, Apr 16, 2016 at 2:22 AM, Brian Kelley  wrote:

> Getting the right version of boost can be tricky.  You can see our normal
> cmake incantation here as well as how we set RDBASE for tests
>
> https://github.com/rdkit/rdkit/blob/master/.travis.yml
>
> Note the
>
> -D Boost_NO_SYSTEM_PATHS=ON
>
> When running cmake, otherwise cmake can get very confused.
>
>
> 
> Brian Kelley
>
> On Apr 15, 2016, at 6:26 PM, Matthew Lardy  wrote:
>
> I'll add, that remembering that cmake and ccmake can produce different
> outcomes I've gone back to trying cmake.  But I can't overwrite the
> variables in cmake.  Here are the results from trying to specify them:
>
>  Manually-specified variables were not used by the project:
>
> BOOST_DIR
> BOOST_INCLUDE_DIR
> BOOST_LIBRARY_DIR
> BOOST_PYTHON_LIBRARY_DEBUG
> BOOST_PYTHON_LIBRARY_RELEASE
> BOOST_REGEX_LIBRARY_DEBUG
> BOOST_REGEX_LIBRARY_RELEASE
> BOOST_SERIALIZATION_LIBRARY_DEBUG
> BOOST_SERIALIZATION_LIBRARY_RELEASE
> BOOST_SYSTEM_LIBRARY_DEBUG
> BOOST_SYSTEM_LIBRARY_RELEASE
> BOOST_THREAD_LIBRARY_DEBUG
> BOOST_THREAD_LIBRARY_RELEASE
>
> cmake, as per it's usual, picked up an ancient version of boost (which I
> want to override).  I can get around this with ccmake, but nothing that I
> compile can pass all of the tests.  If someone knows what these variables
> (shown in ccmake) are called, I'd love to know.
>
> Thanks in advance!
> Matthew
>
>
> On Fri, Apr 15, 2016 at 2:58 PM, Matthew Lardy  wrote:
>
>> Hi all,
>>
>> If someone has an insight I would love to hear it about how best to build
>> RDKit from scratch.
>>
>> I am using the following to build the 2015.03 release:
>> RedHat Linux version 6.4
>> gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
>> swig version 3.0.8
>> cmake version 3.0.0
>> boost version 1.53.0 (I've also tried boost 1.59.0)
>> python version 2.7.7
>>
>> I use ccmake and alter the things which need to be altered (as cmake
>> always grabs the wrong things for me).  My build compiles nicely, and
>> without errors.  But the tests are a mess.  Here is the summary of my build:
>>
>> 26% tests passed, 87 tests failed out of 118
>>
>> I've put the details of the tests, in the hope that someone sees a
>> pattern that I do not, below.
>>
>> Before someone recommends a clean install that is not possible.  I also
>> do not have root, so I can't just wipe the machine and start over.  I
>> cannot use an RPM, so that is out too.  Any ideas are welcome!
>>
>> Thanks,
>> Matthew
>>
>> The following tests FAILED:
>>   2 - testDataStructs (OTHER_FAULT)
>>   3 - pyBV (Failed)
>>   4 - pyDiscreteValueVect (Failed)
>>   5 - pySparseIntVect (Failed)
>>   7 - testGrid (OTHER_FAULT)
>>   8 - testPyGeometry (Failed)
>>  11 - pyAlignment (Failed)
>>  14 - testMMFFForceField (OTHER_FAULT)
>>  15 - pyForceFieldConstraints (Failed)
>>  17 - pyDistGeom (Failed)
>>  18 - graphmolTest1 (OTHER_FAULT)
>>  21 - graphmolMolOpsTest (SEGFAULT)
>>  23 - graphmoltestChirality (OTHER_FAULT)
>>  24 - graphmoltestPickler (OTHER_FAULT)
>>  26 - hanoiTest (OTHER_FAULT)
>>  28 - testDepictor (OTHER_FAULT)
>>  29 - pyDepictor (Failed)
>>  32 - fileParsersTest1 (OTHER_FAULT)
>>  33 - testMolSupplier (OTHER_FAULT)
>>  34 - testMolWriter (OTHER_FAULT)
>>  35 - testTplParser (OTHER_FAULT)
>>  36 - testMol2ToMol (OTHER_FAULT)
>>  38 - testReaction (OTHER_FAULT)
>>  40 - pyChemReactions (Failed)
>>  41 - testChemTransforms (OTHER_FAULT)
>>  44 - testFragCatalog (OTHER_FAULT)
>>  45 - pyFragCatalog (Failed)
>>  46 - testDescriptors (OTHER_FAULT)
>>  47 - pyMolDescriptors (Failed)
>>  48 - testFingerprints (OTHER_FAULT)
>>  50 - pyPartialCharges (Failed)
>>  51 - testMolTransforms (OTHER_FAULT)
>>  52 - pyMolTransforms (Failed)
>>  53 - testMMFFForceFieldHelpers (OTHER_FAULT)
>>  54 - testUFFForceFieldHelpers (OTHER_FAULT)
>>  55 - pyForceFieldHelpers (Failed)
>>  56 - testDistGeomHelpers (OTHER_FAULT)
>>  57 - pyDistGeom (Failed)
>>  58 - testMolAlign (OTHER_FAULT)
>>  59 - pyMolAlign (Failed)

Re: [Rdkit-discuss] RDKit build issues

[Brian Kelley]

Getting the right version of boost can be tricky.  You can see our normal cmake 
incantation here as well as how we set RDBASE for tests

https://github.com/rdkit/rdkit/blob/master/.travis.yml

Note the 

-D Boost_NO_SYSTEM_PATHS=ON

When running cmake, otherwise cmake can get very confused.



Brian Kelley

> On Apr 15, 2016, at 6:26 PM, Matthew Lardy  wrote:
> 
> I'll add, that remembering that cmake and ccmake can produce different 
> outcomes I've gone back to trying cmake.  But I can't overwrite the variables 
> in cmake.  Here are the results from trying to specify them:
> 
>  Manually-specified variables were not used by the project:
> 
> BOOST_DIR
> BOOST_INCLUDE_DIR
> BOOST_LIBRARY_DIR
> BOOST_PYTHON_LIBRARY_DEBUG
> BOOST_PYTHON_LIBRARY_RELEASE
> BOOST_REGEX_LIBRARY_DEBUG
> BOOST_REGEX_LIBRARY_RELEASE
> BOOST_SERIALIZATION_LIBRARY_DEBUG
> BOOST_SERIALIZATION_LIBRARY_RELEASE
> BOOST_SYSTEM_LIBRARY_DEBUG
> BOOST_SYSTEM_LIBRARY_RELEASE
> BOOST_THREAD_LIBRARY_DEBUG
> BOOST_THREAD_LIBRARY_RELEASE
> 
> cmake, as per it's usual, picked up an ancient version of boost (which I want 
> to override).  I can get around this with ccmake, but nothing that I compile 
> can pass all of the tests.  If someone knows what these variables (shown in 
> ccmake) are called, I'd love to know.
> 
> Thanks in advance!
> Matthew
> 
> 
>> On Fri, Apr 15, 2016 at 2:58 PM, Matthew Lardy  wrote:
>> Hi all,
>> 
>> If someone has an insight I would love to hear it about how best to build 
>> RDKit from scratch.  
>> 
>> I am using the following to build the 2015.03 release:
>> RedHat Linux version 6.4
>> gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
>> swig version 3.0.8
>> cmake version 3.0.0
>> boost version 1.53.0 (I've also tried boost 1.59.0)
>> python version 2.7.7
>> 
>> I use ccmake and alter the things which need to be altered (as cmake always 
>> grabs the wrong things for me).  My build compiles nicely, and without 
>> errors.  But the tests are a mess.  Here is the summary of my build:
>> 
>> 26% tests passed, 87 tests failed out of 118
>> 
>> I've put the details of the tests, in the hope that someone sees a pattern 
>> that I do not, below.
>> 
>> Before someone recommends a clean install that is not possible.  I also do 
>> not have root, so I can't just wipe the machine and start over.  I cannot 
>> use an RPM, so that is out too.  Any ideas are welcome!
>> 
>> Thanks,
>> Matthew
>> 
>> The following tests FAILED:
>>   2 - testDataStructs (OTHER_FAULT)
>>   3 - pyBV (Failed)
>>   4 - pyDiscreteValueVect (Failed)
>>   5 - pySparseIntVect (Failed)
>>   7 - testGrid (OTHER_FAULT)
>>   8 - testPyGeometry (Failed)
>>  11 - pyAlignment (Failed)
>>  14 - testMMFFForceField (OTHER_FAULT)
>>  15 - pyForceFieldConstraints (Failed)
>>  17 - pyDistGeom (Failed)
>>  18 - graphmolTest1 (OTHER_FAULT)
>>  21 - graphmolMolOpsTest (SEGFAULT)
>>  23 - graphmoltestChirality (OTHER_FAULT)
>>  24 - graphmoltestPickler (OTHER_FAULT)
>>  26 - hanoiTest (OTHER_FAULT)
>>  28 - testDepictor (OTHER_FAULT)
>>  29 - pyDepictor (Failed)
>>  32 - fileParsersTest1 (OTHER_FAULT)
>>  33 - testMolSupplier (OTHER_FAULT)
>>  34 - testMolWriter (OTHER_FAULT)
>>  35 - testTplParser (OTHER_FAULT)
>>  36 - testMol2ToMol (OTHER_FAULT)
>>  38 - testReaction (OTHER_FAULT)
>>  40 - pyChemReactions (Failed)
>>  41 - testChemTransforms (OTHER_FAULT)
>>  44 - testFragCatalog (OTHER_FAULT)
>>  45 - pyFragCatalog (Failed)
>>  46 - testDescriptors (OTHER_FAULT)
>>  47 - pyMolDescriptors (Failed)
>>  48 - testFingerprints (OTHER_FAULT)
>>  50 - pyPartialCharges (Failed)
>>  51 - testMolTransforms (OTHER_FAULT)
>>  52 - pyMolTransforms (Failed)
>>  53 - testMMFFForceFieldHelpers (OTHER_FAULT)
>>  54 - testUFFForceFieldHelpers (OTHER_FAULT)
>>  55 - pyForceFieldHelpers (Failed)
>>  56 - testDistGeomHelpers (OTHER_FAULT)
>>  57 - pyDistGeom (Failed)
>>  58 - testMolAlign (OTHER_FAULT)
>>  59 - pyMolAlign (Failed)
>>  60 - testFeatures (OTHER_FAULT)
>>  61 - pyChemicalFeatures (Failed)
>>  62 - testShapeHelpers (OTHER_FAULT)
>>  63 - pyShapeHelpers (Failed)
>>  65 - pyMolCatalog (Failed)
>>  66 - moldraw2DTest1 (OTHER_FAULT)
>>  67 - pyMolDraw2D (Failed)
>>  69 - pyFMCS (Failed)
>>  72 - pyMolHash (Failed)
>>  74 - pySLNParse (Failed)
>>  75 - pyGraphMolWrap (Failed)
>>  76 - pyTestConformerWrap (Failed)
>>  79 - pyMatCalc (Failed)
>>  80 - pySimDivPickers (Failed)
>>  81 - pyRanker (Failed)
>>  83 - pyFeatures (Failed)
>>  

Re: [Rdkit-discuss] RDKit build issues

[Brian Kelley]

This looks suspiciously like you haven't set RDBASE to point to the source 
directory when running the tests.  The tests need to find the data directory 
with the test data.


Brian Kelley

> On Apr 15, 2016, at 6:26 PM, Matthew Lardy  wrote:
> 
> I'll add, that remembering that cmake and ccmake can produce different 
> outcomes I've gone back to trying cmake.  But I can't overwrite the variables 
> in cmake.  Here are the results from trying to specify them:
> 
>  Manually-specified variables were not used by the project:
> 
> BOOST_DIR
> BOOST_INCLUDE_DIR
> BOOST_LIBRARY_DIR
> BOOST_PYTHON_LIBRARY_DEBUG
> BOOST_PYTHON_LIBRARY_RELEASE
> BOOST_REGEX_LIBRARY_DEBUG
> BOOST_REGEX_LIBRARY_RELEASE
> BOOST_SERIALIZATION_LIBRARY_DEBUG
> BOOST_SERIALIZATION_LIBRARY_RELEASE
> BOOST_SYSTEM_LIBRARY_DEBUG
> BOOST_SYSTEM_LIBRARY_RELEASE
> BOOST_THREAD_LIBRARY_DEBUG
> BOOST_THREAD_LIBRARY_RELEASE
> 
> cmake, as per it's usual, picked up an ancient version of boost (which I want 
> to override).  I can get around this with ccmake, but nothing that I compile 
> can pass all of the tests.  If someone knows what these variables (shown in 
> ccmake) are called, I'd love to know.
> 
> Thanks in advance!
> Matthew
> 
> 
>> On Fri, Apr 15, 2016 at 2:58 PM, Matthew Lardy  wrote:
>> Hi all,
>> 
>> If someone has an insight I would love to hear it about how best to build 
>> RDKit from scratch.  
>> 
>> I am using the following to build the 2015.03 release:
>> RedHat Linux version 6.4
>> gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
>> swig version 3.0.8
>> cmake version 3.0.0
>> boost version 1.53.0 (I've also tried boost 1.59.0)
>> python version 2.7.7
>> 
>> I use ccmake and alter the things which need to be altered (as cmake always 
>> grabs the wrong things for me).  My build compiles nicely, and without 
>> errors.  But the tests are a mess.  Here is the summary of my build:
>> 
>> 26% tests passed, 87 tests failed out of 118
>> 
>> I've put the details of the tests, in the hope that someone sees a pattern 
>> that I do not, below.
>> 
>> Before someone recommends a clean install that is not possible.  I also do 
>> not have root, so I can't just wipe the machine and start over.  I cannot 
>> use an RPM, so that is out too.  Any ideas are welcome!
>> 
>> Thanks,
>> Matthew
>> 
>> The following tests FAILED:
>>   2 - testDataStructs (OTHER_FAULT)
>>   3 - pyBV (Failed)
>>   4 - pyDiscreteValueVect (Failed)
>>   5 - pySparseIntVect (Failed)
>>   7 - testGrid (OTHER_FAULT)
>>   8 - testPyGeometry (Failed)
>>  11 - pyAlignment (Failed)
>>  14 - testMMFFForceField (OTHER_FAULT)
>>  15 - pyForceFieldConstraints (Failed)
>>  17 - pyDistGeom (Failed)
>>  18 - graphmolTest1 (OTHER_FAULT)
>>  21 - graphmolMolOpsTest (SEGFAULT)
>>  23 - graphmoltestChirality (OTHER_FAULT)
>>  24 - graphmoltestPickler (OTHER_FAULT)
>>  26 - hanoiTest (OTHER_FAULT)
>>  28 - testDepictor (OTHER_FAULT)
>>  29 - pyDepictor (Failed)
>>  32 - fileParsersTest1 (OTHER_FAULT)
>>  33 - testMolSupplier (OTHER_FAULT)
>>  34 - testMolWriter (OTHER_FAULT)
>>  35 - testTplParser (OTHER_FAULT)
>>  36 - testMol2ToMol (OTHER_FAULT)
>>  38 - testReaction (OTHER_FAULT)
>>  40 - pyChemReactions (Failed)
>>  41 - testChemTransforms (OTHER_FAULT)
>>  44 - testFragCatalog (OTHER_FAULT)
>>  45 - pyFragCatalog (Failed)
>>  46 - testDescriptors (OTHER_FAULT)
>>  47 - pyMolDescriptors (Failed)
>>  48 - testFingerprints (OTHER_FAULT)
>>  50 - pyPartialCharges (Failed)
>>  51 - testMolTransforms (OTHER_FAULT)
>>  52 - pyMolTransforms (Failed)
>>  53 - testMMFFForceFieldHelpers (OTHER_FAULT)
>>  54 - testUFFForceFieldHelpers (OTHER_FAULT)
>>  55 - pyForceFieldHelpers (Failed)
>>  56 - testDistGeomHelpers (OTHER_FAULT)
>>  57 - pyDistGeom (Failed)
>>  58 - testMolAlign (OTHER_FAULT)
>>  59 - pyMolAlign (Failed)
>>  60 - testFeatures (OTHER_FAULT)
>>  61 - pyChemicalFeatures (Failed)
>>  62 - testShapeHelpers (OTHER_FAULT)
>>  63 - pyShapeHelpers (Failed)
>>  65 - pyMolCatalog (Failed)
>>  66 - moldraw2DTest1 (OTHER_FAULT)
>>  67 - pyMolDraw2D (Failed)
>>  69 - pyFMCS (Failed)
>>  72 - pyMolHash (Failed)
>>  74 - pySLNParse (Failed)
>>  75 - pyGraphMolWrap (Failed)
>>  76 - pyTestConformerWrap (Failed)
>>  79 - pyMatCalc (Failed)
>>  80 - pySimDivPickers (Failed)
>>  81 - pyRanker (Failed)
>>  83 - pyFeatures (Failed)
>>  84 - JavaAromaticTests (Failed)
>>  85 - JavaAtomPairsTests (Failed)
>>  86 - JavaBasicMoleculeTests 

Re: [Rdkit-discuss] RDKit build issues

[Matthew Lardy]

I'll add, that remembering that cmake and ccmake can produce different
outcomes I've gone back to trying cmake.  But I can't overwrite the
variables in cmake.  Here are the results from trying to specify them:

 Manually-specified variables were not used by the project:

BOOST_DIR
BOOST_INCLUDE_DIR
BOOST_LIBRARY_DIR
BOOST_PYTHON_LIBRARY_DEBUG
BOOST_PYTHON_LIBRARY_RELEASE
BOOST_REGEX_LIBRARY_DEBUG
BOOST_REGEX_LIBRARY_RELEASE
BOOST_SERIALIZATION_LIBRARY_DEBUG
BOOST_SERIALIZATION_LIBRARY_RELEASE
BOOST_SYSTEM_LIBRARY_DEBUG
BOOST_SYSTEM_LIBRARY_RELEASE
BOOST_THREAD_LIBRARY_DEBUG
BOOST_THREAD_LIBRARY_RELEASE

cmake, as per it's usual, picked up an ancient version of boost (which I
want to override).  I can get around this with ccmake, but nothing that I
compile can pass all of the tests.  If someone knows what these variables
(shown in ccmake) are called, I'd love to know.

Thanks in advance!
Matthew


On Fri, Apr 15, 2016 at 2:58 PM, Matthew Lardy  wrote:

> Hi all,
>
> If someone has an insight I would love to hear it about how best to build
> RDKit from scratch.
>
> I am using the following to build the 2015.03 release:
> RedHat Linux version 6.4
> gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
> swig version 3.0.8
> cmake version 3.0.0
> boost version 1.53.0 (I've also tried boost 1.59.0)
> python version 2.7.7
>
> I use ccmake and alter the things which need to be altered (as cmake
> always grabs the wrong things for me).  My build compiles nicely, and
> without errors.  But the tests are a mess.  Here is the summary of my build:
>
> 26% tests passed, 87 tests failed out of 118
>
> I've put the details of the tests, in the hope that someone sees a pattern
> that I do not, below.
>
> Before someone recommends a clean install that is not possible.  I also do
> not have root, so I can't just wipe the machine and start over.  I cannot
> use an RPM, so that is out too.  Any ideas are welcome!
>
> Thanks,
> Matthew
>
> The following tests FAILED:
>   2 - testDataStructs (OTHER_FAULT)
>   3 - pyBV (Failed)
>   4 - pyDiscreteValueVect (Failed)
>   5 - pySparseIntVect (Failed)
>   7 - testGrid (OTHER_FAULT)
>   8 - testPyGeometry (Failed)
>  11 - pyAlignment (Failed)
>  14 - testMMFFForceField (OTHER_FAULT)
>  15 - pyForceFieldConstraints (Failed)
>  17 - pyDistGeom (Failed)
>  18 - graphmolTest1 (OTHER_FAULT)
>  21 - graphmolMolOpsTest (SEGFAULT)
>  23 - graphmoltestChirality (OTHER_FAULT)
>  24 - graphmoltestPickler (OTHER_FAULT)
>  26 - hanoiTest (OTHER_FAULT)
>  28 - testDepictor (OTHER_FAULT)
>  29 - pyDepictor (Failed)
>  32 - fileParsersTest1 (OTHER_FAULT)
>  33 - testMolSupplier (OTHER_FAULT)
>  34 - testMolWriter (OTHER_FAULT)
>  35 - testTplParser (OTHER_FAULT)
>  36 - testMol2ToMol (OTHER_FAULT)
>  38 - testReaction (OTHER_FAULT)
>  40 - pyChemReactions (Failed)
>  41 - testChemTransforms (OTHER_FAULT)
>  44 - testFragCatalog (OTHER_FAULT)
>  45 - pyFragCatalog (Failed)
>  46 - testDescriptors (OTHER_FAULT)
>  47 - pyMolDescriptors (Failed)
>  48 - testFingerprints (OTHER_FAULT)
>  50 - pyPartialCharges (Failed)
>  51 - testMolTransforms (OTHER_FAULT)
>  52 - pyMolTransforms (Failed)
>  53 - testMMFFForceFieldHelpers (OTHER_FAULT)
>  54 - testUFFForceFieldHelpers (OTHER_FAULT)
>  55 - pyForceFieldHelpers (Failed)
>  56 - testDistGeomHelpers (OTHER_FAULT)
>  57 - pyDistGeom (Failed)
>  58 - testMolAlign (OTHER_FAULT)
>  59 - pyMolAlign (Failed)
>  60 - testFeatures (OTHER_FAULT)
>  61 - pyChemicalFeatures (Failed)
>  62 - testShapeHelpers (OTHER_FAULT)
>  63 - pyShapeHelpers (Failed)
>  65 - pyMolCatalog (Failed)
>  66 - moldraw2DTest1 (OTHER_FAULT)
>  67 - pyMolDraw2D (Failed)
>  69 - pyFMCS (Failed)
>  72 - pyMolHash (Failed)
>  74 - pySLNParse (Failed)
>  75 - pyGraphMolWrap (Failed)
>  76 - pyTestConformerWrap (Failed)
>  79 - pyMatCalc (Failed)
>  80 - pySimDivPickers (Failed)
>  81 - pyRanker (Failed)
>  83 - pyFeatures (Failed)
>  84 - JavaAromaticTests (Failed)
>  85 - JavaAtomPairsTests (Failed)
>  86 - JavaBasicMoleculeTests (Failed)
>  87 - JavaBasicMolecule2Tests (Failed)
>  88 - JavaChemAtomTests (Failed)
>  89 - JavaChemBondTests (Failed)
>  90 - JavaChemReactionTests (Failed)
>  91 - JavaChemSmartsTests (Failed)
>  92 - JavaChemTests (Failed)
>  93 - JavaChemv2Tests (Failed)
>  94 - JavaConformerTests (Failed)
>  95 - JavaDescriptorTests (Failed)
>  96 -