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