rdkit-devel

[Rdkit-devel] Beta of Q2 2011 Release Available

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

Dear all,

This morning I tagged the beta for the Q2 2011 (2011.06 in the new
numbering) release in svn:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_2011_06_1beta1/

and uploaded a source distribution to the google code site:
http://code.google.com/p/rdkit/downloads/detail?name=RDKit_2011_06_1beta1.tgz
If there's demand for it, I will also put up a windows binary.

As usual: if no show-stopper bugs appear, I will do the release itself
in about a week.

Excerpts from the release notes are below.

One highlight I will call your attention to is that, thanks to some
nice work from Eddie Cao, it is now possible to generate InChI codes
from within the RDKit :

In [2]: inchi = Chem.MolToInchi(Chem.MolFromSmiles('c1ccccc1C(=O)O'))
In [3]: print inchi
InChI=1S/C7H6O2/c8-7(9)6-4-2-1-3-5-6/h1-5H,(H,8,9)

and then convert the InChIs to InChI keys:

In [4]: print Chem.InchiToInchiKey(inchi)
WPYMKLBDIGXBTP-UHFFFAOYSA-N

There is also experimental and partial support for converting InChI
back into a molecule:

In [5]: m2 = Chem.MolFromInchi(inchi)
In [6]: print Chem.MolToSmiles(m2)
O=C(O)c1ccccc1

Note that this last bit is not something InChI is actually designed
for, so it's probably not a good idea to rely on it.



Best Regards,
-greg


******  Release_2011.06.1 *******
(Changes relative to Release_2011.03.2)

Acknowledgements:
 - Eddie Cao, Andrew Dalke, James Davidson, JP Ebejer, Bernd Wiswedel

Bug Fixes:
 - A problem with similarity values between SparseIntVects that
   contain negative values was fixed. (Issue 3295215)
 - An edge case in SmilesMolSupplier.GetItemText() was fixed. (Issue
   3299878)
 - The drawing code now uses dashed lines for aromatic bonds without
   kekulization. (Issue 3305420)
 - AllChem.ConstrainedEmbed works again. (Issue 3305420)
 - atomic RGP values from mol files are accessible from python (Issue
   3313539)
 - M RGP blocks are now written to mol files. (Issue 3313540)
 - Atom.GetSymbol() for R atoms read from mol files is now
   correct. (Issue 3316600)
 - The handling of isotope specifications is more robust.
 - A thread-safety problem in SmilesWrite::GetAtomSmiles() was fixed.
 - some of the MACCS keys definitions have been corrected

New Features:
 - The smiles, smarts, and reaction smarts parsers all now take an additional
   argument, "replacements", that carries out string substitutions pre-parsing.
 - There is now optional support for generating InChI codes and keys
   for molecules.
 - the atom pair and topological torsion fingerprint generators now
   take an optional "ignoreAtoms" argument
 - a function to calculate exact molecular weight was added.
 - new java wrappers are now available in $RDBASE/Code/JavaWrappers
 - the methods getMostCommonIsotope() and getMostCommonIsotopeMass()
   have been added to the PeriodicTable class.

New Database Cartridge Features:

Deprecated modules (to be removed in next release):
 - The original SWIG wrappers in $RDBASE/Code/Demos/SWIG are deprecated

Removed modules:

Other:
 - The quality of the drawings produced by both the python molecule drawing
   code and $RDBASE/Code/Demos/RDKit/Draw is better.
 - the python molecule drawing code will now use superscripts and
   subscripts appropriately when using the aggdraw or cairo canvases
   (cairo canvas requires pango for this to work).
 - $RDBASE/Code/Demos/RDKit/Draw now includes an example using cairo
 - A lot of compiler warnings were cleaned up.
 - The error reporting in the SMILES, SMARTS, and SLN parsers was improved.
 - the code for calculating molecular formula is now in C++
   (Descriptors::calcMolFormula())

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

[Robert D. <rkd...@gm...>]

It works here on CentOS 5.6.  Testing with my code goes fine, but the test
step (ctest from the build directory) results in 72/76 tests failed.
Problem with the test DB?





On Fri, Jul 1, 2011 at 5:40 AM, Greg Landrum <gre...@gm...> wrote:

> Dear all,
>
> This morning I tagged the beta for the Q2 2011 (2011.06 in the new
> numbering) release in svn:
> http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_2011_06_1beta1/
>
> and uploaded a source distribution to the google code site:
>
> http://code.google.com/p/rdkit/downloads/detail?name=RDKit_2011_06_1beta1.tgz
> If there's demand for it, I will also put up a windows binary.
>
> As usual: if no show-stopper bugs appear, I will do the release itself
> in about a week.
>
> Excerpts from the release notes are below.
>
> One highlight I will call your attention to is that, thanks to some
> nice work from Eddie Cao, it is now possible to generate InChI codes
> from within the RDKit :
>
> In [2]: inchi = Chem.MolToInchi(Chem.MolFromSmiles('c1ccccc1C(=O)O'))
> In [3]: print inchi
> InChI=1S/C7H6O2/c8-7(9)6-4-2-1-3-5-6/h1-5H,(H,8,9)
>
> and then convert the InChIs to InChI keys:
>
> In [4]: print Chem.InchiToInchiKey(inchi)
> WPYMKLBDIGXBTP-UHFFFAOYSA-N
>
> There is also experimental and partial support for converting InChI
> back into a molecule:
>
> In [5]: m2 = Chem.MolFromInchi(inchi)
> In [6]: print Chem.MolToSmiles(m2)
> O=C(O)c1ccccc1
>
> Note that this last bit is not something InChI is actually designed
> for, so it's probably not a good idea to rely on it.
>
>
>
> Best Regards,
> -greg
>
>
> ******  Release_2011.06.1 *******
> (Changes relative to Release_2011.03.2)
>
> Acknowledgements:
>  - Eddie Cao, Andrew Dalke, James Davidson, JP Ebejer, Bernd Wiswedel
>
> Bug Fixes:
>  - A problem with similarity values between SparseIntVects that
>   contain negative values was fixed. (Issue 3295215)
>  - An edge case in SmilesMolSupplier.GetItemText() was fixed. (Issue
>   3299878)
>  - The drawing code now uses dashed lines for aromatic bonds without
>   kekulization. (Issue 3305420)
>  - AllChem.ConstrainedEmbed works again. (Issue 3305420)
>  - atomic RGP values from mol files are accessible from python (Issue
>   3313539)
>  - M RGP blocks are now written to mol files. (Issue 3313540)
>  - Atom.GetSymbol() for R atoms read from mol files is now
>   correct. (Issue 3316600)
>  - The handling of isotope specifications is more robust.
>  - A thread-safety problem in SmilesWrite::GetAtomSmiles() was fixed.
>  - some of the MACCS keys definitions have been corrected
>
> New Features:
>  - The smiles, smarts, and reaction smarts parsers all now take an
> additional
>   argument, "replacements", that carries out string substitutions
> pre-parsing.
>  - There is now optional support for generating InChI codes and keys
>   for molecules.
>  - the atom pair and topological torsion fingerprint generators now
>   take an optional "ignoreAtoms" argument
>  - a function to calculate exact molecular weight was added.
>  - new java wrappers are now available in $RDBASE/Code/JavaWrappers
>  - the methods getMostCommonIsotope() and getMostCommonIsotopeMass()
>   have been added to the PeriodicTable class.
>
> New Database Cartridge Features:
>
> Deprecated modules (to be removed in next release):
>  - The original SWIG wrappers in $RDBASE/Code/Demos/SWIG are deprecated
>
> Removed modules:
>
> Other:
>  - The quality of the drawings produced by both the python molecule drawing
>   code and $RDBASE/Code/Demos/RDKit/Draw is better.
>  - the python molecule drawing code will now use superscripts and
>   subscripts appropriately when using the aggdraw or cairo canvases
>   (cairo canvas requires pango for this to work).
>  - $RDBASE/Code/Demos/RDKit/Draw now includes an example using cairo
>  - A lot of compiler warnings were cleaned up.
>  - The error reporting in the SMILES, SMARTS, and SLN parsers was improved.
>  - the code for calculating molecular formula is now in C++
>   (Descriptors::calcMolFormula())
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

On Fri, Jul 1, 2011 at 1:40 PM, Greg Landrum <gre...@gm...> wrote:

> One highlight I will call your attention to is that, thanks to some
> nice work from Eddie Cao, it is now possible to generate InChI codes
> from within the RDKit :

I just tried to build the beta into RPM packages; I've read that inchi
support is optional, so I guess there is a new cmake switch to trigger
it. However, all py* tests are now failing because "from inchi import
*" gives an ImportError.

Probably I'm missing something obvious here, but given that import
line is in rdkit/Chem/__init__.py  that means python bindings are
basically unusable right now unless you also activate Inchi support.


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

Moving just to the -developers list.

On Thu, Jul 7, 2011 at 9:53 AM, Gianluca Sforna <gi...@gm...> wrote:
> On Fri, Jul 1, 2011 at 1:40 PM, Greg Landrum <gre...@gm...> wrote:
>
>> One highlight I will call your attention to is that, thanks to some
>> nice work from Eddie Cao, it is now possible to generate InChI codes
>> from within the RDKit :
>
> I just tried to build the beta into RPM packages; I've read that inchi
> support is optional, so I guess there is a new cmake switch to trigger
> it. However, all py* tests are now failing because "from inchi import
> *" gives an ImportError.

That's defniitely not what's supposed to happen (and isn't what
happens for me when doing the standard in-tree install).

> Probably I'm missing something obvious here, but given that import
> line is in rdkit/Chem/__init__.py  that means python bindings are
> basically unusable right now unless you also activate Inchi support.

If you don't do the inchi installation cmake should create a file
$RDBASE/rdkit/Chem/inchi.py that is basically empty.

-greg

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

On Thu, Jul 7, 2011 at 3:35 PM, Greg Landrum <gre...@gm...> wrote:
> Moving just to the -developers list.
>
> On Thu, Jul 7, 2011 at 9:53 AM, Gianluca Sforna <gi...@gm...> wrote:
>> On Fri, Jul 1, 2011 at 1:40 PM, Greg Landrum <gre...@gm...> wrote:
>>
>>> One highlight I will call your attention to is that, thanks to some
>>> nice work from Eddie Cao, it is now possible to generate InChI codes
>>> from within the RDKit :
>>
>> I just tried to build the beta into RPM packages; I've read that inchi
>> support is optional, so I guess there is a new cmake switch to trigger
>> it. However, all py* tests are now failing because "from inchi import
>> *" gives an ImportError.
>
> That's defniitely not what's supposed to happen (and isn't what
> happens for me when doing the standard in-tree install).
>

I gave a look to the CMake listfile that manages the InChI code and
I'm investigating a possible reason for this unexpected behavior. As
far as I can remember, two different build workflows allowed tests
execution. One is "build outside the source dir, install in-tree,
test", more supported and documented, useful when developing, but not
very convenient when packaging; the other is "build in-tree, test,
install into a tree that mimics the system locations". It is not very
useful during the development, but produces the tested libraries
organized in a way which is more convenient when packaging.

In particular, since the testing code was designed for an in-tree
installation, this second workflow relies on cmake producing the
output from the build in locations under ${CMAKE_BUILD_DIR} that match
those same locations that installing in-tree determines under
${CMAKE_SOURCE_DIR}. This way, when building in-tree,
${CMAKE_BUILD_DIR} and ${CMAKE_SOURCE_DIR} are the same and the files
resulting from the build are placed where the test code expects them.

I'm sorry if I was confusing, but here's the shorter version. If I
understood it correctly, the selected inchi.py is copied into
${CMAKE_CURRENT_BINARY_DIR} at build time and placed into rdkit/Chem
only when installing. Since the second workflow above runs tests prior
to the installation step the tests fail because inchi.py is not yet
available inside the python tree. Copying to
${CMAKE_BINARY_DIR}/rdkit/Chem/inchi.py should work in both cases. I
tested this with the second workflow on a fresh snapshot and tests
pass (at least up to 57/76 testMolSupplier, which seems to hang
forever, I didn't experience this on earlier linux installations, but
I know this test is also problematic for MinGW, so I think this
problem is probably unrelated). For clarity, I'm attaching the small
patch I used (in-tree and with inchi support branches are untested).

Hope that helps,

Best regards,
Riccardo


>> Probably I'm missing something obvious here, but given that import
>> line is in rdkit/Chem/__init__.py  that means python bindings are
>> basically unusable right now unless you also activate Inchi support.
>
> If you don't do the inchi installation cmake should create a file
> $RDBASE/rdkit/Chem/inchi.py that is basically empty.
>
> -greg
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

[Eddie C. <cao...@gm...>]

Hi Riccardo,

Thanks for the analysis. I think you are right about the cause of the problem. When writing the CMake listfile, I never thought about the second workflow, and I assumed tests were always done after installation. The implication is that the source is essentially in incomplete state and missing a proper inchi.py until `make install` is run.

I think your patch - without the typo at the end - should solve the problem. I will patch the source later in case other concerns are raised.

Thanks,
Eddie

On Jul 7, 2011, at 3:01 PM, Riccardo Vianello wrote:

> On Thu, Jul 7, 2011 at 3:35 PM, Greg Landrum <gre...@gm...> wrote:
>> Moving just to the -developers list.
>> 
>> On Thu, Jul 7, 2011 at 9:53 AM, Gianluca Sforna <gi...@gm...> wrote:
>>> On Fri, Jul 1, 2011 at 1:40 PM, Greg Landrum <gre...@gm...> wrote:
>>> 
>>>> One highlight I will call your attention to is that, thanks to some
>>>> nice work from Eddie Cao, it is now possible to generate InChI codes
>>>> from within the RDKit :
>>> 
>>> I just tried to build the beta into RPM packages; I've read that inchi
>>> support is optional, so I guess there is a new cmake switch to trigger
>>> it. However, all py* tests are now failing because "from inchi import
>>> *" gives an ImportError.
>> 
>> That's defniitely not what's supposed to happen (and isn't what
>> happens for me when doing the standard in-tree install).
>> 
> 
> I gave a look to the CMake listfile that manages the InChI code and
> I'm investigating a possible reason for this unexpected behavior. As
> far as I can remember, two different build workflows allowed tests
> execution. One is "build outside the source dir, install in-tree,
> test", more supported and documented, useful when developing, but not
> very convenient when packaging; the other is "build in-tree, test,
> install into a tree that mimics the system locations". It is not very
> useful during the development, but produces the tested libraries
> organized in a way which is more convenient when packaging.
> 
> In particular, since the testing code was designed for an in-tree
> installation, this second workflow relies on cmake producing the
> output from the build in locations under ${CMAKE_BUILD_DIR} that match
> those same locations that installing in-tree determines under
> ${CMAKE_SOURCE_DIR}. This way, when building in-tree,
> ${CMAKE_BUILD_DIR} and ${CMAKE_SOURCE_DIR} are the same and the files
> resulting from the build are placed where the test code expects them.
> 
> I'm sorry if I was confusing, but here's the shorter version. If I
> understood it correctly, the selected inchi.py is copied into
> ${CMAKE_CURRENT_BINARY_DIR} at build time and placed into rdkit/Chem
> only when installing. Since the second workflow above runs tests prior
> to the installation step the tests fail because inchi.py is not yet
> available inside the python tree. Copying to
> ${CMAKE_BINARY_DIR}/rdkit/Chem/inchi.py should work in both cases. I
> tested this with the second workflow on a fresh snapshot and tests
> pass (at least up to 57/76 testMolSupplier, which seems to hang
> forever, I didn't experience this on earlier linux installations, but
> I know this test is also problematic for MinGW, so I think this
> problem is probably unrelated). For clarity, I'm attaching the small
> patch I used (in-tree and with inchi support branches are untested).
> 
> Hope that helps,
> 
> Best regards,
> Riccardo
> 
> 
>>> Probably I'm missing something obvious here, but given that import
>>> line is in rdkit/Chem/__init__.py  that means python bindings are
>>> basically unusable right now unless you also activate Inchi support.
>> 
>> If you don't do the inchi installation cmake should create a file
>> $RDBASE/rdkit/Chem/inchi.py that is basically empty.
>> 
>> -greg
>> 
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rdkit-devel mailing list
>> Rdk...@li...
>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>> 
> <inchi_test.diff>------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2_______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

On Thu, Jul 7, 2011 at 3:35 PM, Greg Landrum <gre...@gm...> wrote:
> On Thu, Jul 7, 2011 at 9:53 AM, Gianluca Sforna <gi...@gm...> wrote:
>> I just tried to build the beta into RPM packages; I've read that inchi
>> support is optional, so I guess there is a new cmake switch to trigger
>> it. However, all py* tests are now failing because "from inchi import
>> *" gives an ImportError.
>
> That's defniitely not what's supposed to happen (and isn't what
> happens for me when doing the standard in-tree install).

Now I see. The problem is that I'd need some help from your side to
also support some alternate standards, otherwise building proper
packages for end users is increasingly painful.

>
>> Probably I'm missing something obvious here, but given that import
>> line is in rdkit/Chem/__init__.py  that means python bindings are
>> basically unusable right now unless you also activate Inchi support.
>
> If you don't do the inchi installation cmake should create a file
> $RDBASE/rdkit/Chem/inchi.py that is basically empty.

So, examined this part a bit more and unfortunately, the feature as is
makes packaging harder: the main issue is that we will need to use the
system's provided inchi library but right now the build lacks any
support for that. In practice, I think I'd suggest:

1. add an option to build or not inchi support
2. add an option to use system's provided inchi
3. ensure tests works also before the in-tree install
4. skip inchi feature tests if disabled

For reference, I found OpenBabel is doing something very similar:
https://openbabel.svn.sourceforge.net/svnroot/openbabel/openbabel/trunk/CMakeLists.txt
https://openbabel.svn.sourceforge.net/svnroot/openbabel/openbabel/trunk/cmake/modules/FindInchi.cmake

Of course, if you are ok with the plan, I am willing to provide
patches for the above.


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

Hi Gianluca,

On Fri, Jul 8, 2011 at 12:14 AM, Gianluca Sforna <gi...@gm...> wrote:
> On Thu, Jul 7, 2011 at 3:35 PM, Greg Landrum <gre...@gm...> wrote:
>> On Thu, Jul 7, 2011 at 9:53 AM, Gianluca Sforna <gi...@gm...> wrote:
>>> I just tried to build the beta into RPM packages; I've read that inchi
>>> support is optional, so I guess there is a new cmake switch to trigger
>>> it. However, all py* tests are now failing because "from inchi import
>>> *" gives an ImportError.
>>
>> That's defniitely not what's supposed to happen (and isn't what
>> happens for me when doing the standard in-tree install).
>
> Now I see. The problem is that I'd need some help from your side to
> also support some alternate standards, otherwise building proper
> packages for end users is increasingly painful.

Sorry that we created the problem, we will get it fixed. The packaging
work that you're doing is really valuable and I certainly don't want
to make it either more difficult or complex. I will start to make a
habit of doing an out-of-source build to make sure things like this
are less likely to happen again.

>>> Probably I'm missing something obvious here, but given that import
>>> line is in rdkit/Chem/__init__.py  that means python bindings are
>>> basically unusable right now unless you also activate Inchi support.
>>
>> If you don't do the inchi installation cmake should create a file
>> $RDBASE/rdkit/Chem/inchi.py that is basically empty.
>
> So, examined this part a bit more and unfortunately, the feature as is
> makes packaging harder: the main issue is that we will need to use the
> system's provided inchi library but right now the build lacks any
> support for that. In practice, I think I'd suggest:
>
> 1. add an option to build or not inchi support
> 2. add an option to use system's provided inchi
> 3. ensure tests works also before the in-tree install
> 4. skip inchi feature tests if disabled

I agree with all of these.

> For reference, I found OpenBabel is doing something very similar:
> https://openbabel.svn.sourceforge.net/svnroot/openbabel/openbabel/trunk/CMakeLists.txt
> https://openbabel.svn.sourceforge.net/svnroot/openbabel/openbabel/trunk/cmake/modules/FindInchi.cmake
>
> Of course, if you are ok with the plan, I am willing to provide
> patches for the above.

It would be great if you could do that; otherwise Eddie and I will get
something put together today.

Best,
-greg

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

On Fri, Jul 8, 2011 at 5:21 AM, Greg Landrum <gre...@gm...> wrote:
> Hi Gianluca,
>
> On Fri, Jul 8, 2011 at 12:14 AM, Gianluca Sforna <gi...@gm...> wrote:
>> On Thu, Jul 7, 2011 at 3:35 PM, Greg Landrum <gre...@gm...> wrote:
>>> On Thu, Jul 7, 2011 at 9:53 AM, Gianluca Sforna <gi...@gm...> wrote:
>>>> I just tried to build the beta into RPM packages; I've read that inchi
>>>> support is optional, so I guess there is a new cmake switch to trigger
>>>> it. However, all py* tests are now failing because "from inchi import
>>>> *" gives an ImportError.
>>>
>>> That's defniitely not what's supposed to happen (and isn't what
>>> happens for me when doing the standard in-tree install).
>>
>> Now I see. The problem is that I'd need some help from your side to
>> also support some alternate standards, otherwise building proper
>> packages for end users is increasingly painful.
>
> Sorry that we created the problem, we will get it fixed. The packaging
> work that you're doing is really valuable and I certainly don't want
> to make it either more difficult or complex. I will start to make a
> habit of doing an out-of-source build to make sure things like this
> are less likely to happen again.

Thanks Greg, I really appreciate this.
To help you avoid adding burden to development, I was thinking about
starting a buildbot instance somewhere so compilation and tests could
be run regularly with both methods. Did you ever consider such a
setup?


>
> It would be great if you could do that; otherwise Eddie and I will get
> something put together today.

I'm having a look at it right now

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

On Fri, Jul 8, 2011 at 11:01 AM, Gianluca Sforna <gi...@gm...> wrote:
>>>
>>> Now I see. The problem is that I'd need some help from your side to
>>> also support some alternate standards, otherwise building proper
>>> packages for end users is increasingly painful.
>>
>> Sorry that we created the problem, we will get it fixed. The packaging
>> work that you're doing is really valuable and I certainly don't want
>> to make it either more difficult or complex. I will start to make a
>> habit of doing an out-of-source build to make sure things like this
>> are less likely to happen again.
>
> Thanks Greg, I really appreciate this.
> To help you avoid adding burden to development, I was thinking about

I have a script that does the "checkout, build, test" process already.
I just need to create a copy that does the build in-source...
shouldn't be that bad.

> starting a buildbot instance somewhere so compilation and tests could
> be run regularly with both methods. Did you ever consider such a
> setup?

I do nightlies of the Novartis-internal version at work, but I haven't
really looked for anywhere to do the equivalent with the open-source
build. It would be nice to have.

>> It would be great if you could do that; otherwise Eddie and I will get
>> something put together today.
>
> I'm having a look at it right now

I integrated Riccardo's patch and can verify that, with those two
changes made, an in-source build passes the python tests without first
having to do a "make install".

-greg

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

I think we're about there now.
The current svn version has a new configuration flag
(RDK_BUILD_INCHI_SUPPORT) that toggles inclusion of the inchi
wrappers. It defaults to OFF.
If this is set:
   - if $RDBASE/External/INCHI-API/src contains the inchi code, the
local copy will be used.
   - otherwise if a system version is found (using a copy of the
openbabel findinchi.cmake file), that will be used.
   - otherwise a warning will be issued and the use_inchi flag will be
switched off.
In any case the appropriate version of the file inchi.py will be
created in the rdkit/Chem directory at build time.

This ought to all work for in-source and out-of-source builds and
seems to also work with make install

I'd really like to get this release finished soon. Gianluca: can you
please take a look and see if what's there now works for the
packaging?

Thanks,
-greg

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

On Sat, Jul 9, 2011 at 12:23 PM, Greg Landrum <gre...@gm...> wrote:
>
> I'd really like to get this release finished soon. Gianluca: can you
> please take a look and see if what's there now works for the
> packaging?

Sorry for the late reply, I'm in vacation with the family and can
hardly use the PC :)

I tried to update from SVN and rebuild the RPM but now I fail because
I need to update one patch (I still carry a couple of the to disable
completely the static build and linking) so I could not finish it.
I'll need to work on that a bit more before reporting results, however
the approach seems sane so I guess you can go on and release if you
wish

Thanks again

G.

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

Hi Gianluca,

On Mon, Jul 11, 2011 at 12:55 AM, Gianluca Sforna <gi...@gm...> wrote:
> On Sat, Jul 9, 2011 at 12:23 PM, Greg Landrum <gre...@gm...> wrote:
>>
>> I'd really like to get this release finished soon. Gianluca: can you
>> please take a look and see if what's there now works for the
>> packaging?
>
> Sorry for the late reply, I'm in vacation with the family and can
> hardly use the PC :)

That's a pretty good reason. :-)

> I tried to update from SVN and rebuild the RPM but now I fail because
> I need to update one patch (I still carry a couple of the to disable
> completely the static build and linking) so I could not finish it.
> I'll need to work on that a bit more before reporting results, however
> the approach seems sane so I guess you can go on and release if you
> wish

Thanks for taking a look despite being on vacation. Once this release
is wrapped up, I will work on setting up the cmake files so that the
static build can be easily disabled so that you don't have to deal
with the patches.

-greg

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

On Mon, Jul 11, 2011 at 6:19 AM, Greg Landrum <gre...@gm...> wrote:
>
> Thanks for taking a look despite being on vacation. Once this release
> is wrapped up, I will work on setting up the cmake files so that the
> static build can be easily disabled so that you don't have to deal
> with the patches.

Yeah, that would be very useful indeed.

In the meanwhile, I updated the patch and verified the build completes
correctly, also passing all the tests. This is for Fedora 14 x86_64,
will try the same for F15, rawhide (aka F16) and possibly RHEL 6; had
no time to continue the work for porting code to 5.6, sorry :(

Cheers
G.


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu