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
>