Re: [Rdkit-devel] RDKit changes for RHEL/CentOS 5 packaging
Open-Source Cheminformatics and Machine Learning
Brought to you by:
glandrum
|
From: Greg L. <gre...@gm...> - 2011-05-19 03:30:17
|
Dear Gianluca, On Wed, May 18, 2011 at 11:34 AM, Gianluca Sforna <gi...@gm...> wrote: > Since some time, I'm toying with the idea of trying to determine if > and how it is possible to build RDKit against system provided > libraries in a CentOS 5 system; this is a requirement for eventual > inclusion in an official repository. It would certainly be nice to have those packages available, but I suspect this restriction (which I understand) is going to end up being a problem (more below). > Until version 5.6 this was not really possible mainly due to a gcc > bug, which is now fixed. Additionally, Flex is still an issue because > only version 2.5.4a is available for use (but I'm working on this). > > The last issue is boost, as we have 1.33 in the repositories, so I > tried to lower the requirement to see what breaks. I guess I don't really understand how the RHEL guys decide when to update a package. Neither bison nor boost are particularly exotic pieces of software and both are quite widely used, yet the versions of each that are available with these systems is really out of date. > It turned out the > only feature used from the newer boost is the BOOST_FOREACH construct > (there were about 30 in the whole code base), so I just had to > routinely replace it with a regular for loop on the proper iterators. Lovely. I've been doing the opposite (replacing standard for loops with BOOST_FOREACH) whenever I'm working in a file and remember to do so. It makes for somewhat cleaner code. > So, before proceeding further (I have few tests failures to diagnose) > I'd like to hear opinions about this work: surely, I can just add a > patch on the RPM side but it would be nice to avoid the need to keep > maintaining it and eventually rebase it on new releases. I like the BOOST_FOREACH usage, but if that were the only sticking point I'd be more than willing to give it up in the name of having packages available for RHEL. However, it's not the only sticking point. - There was a change in the boost random number generator in version 1.40. This means that fingerprints generated with v1.40 and beyond are not compatible with earlier versions. This is likely to lead to confusion - RHEL is still shipping with only python2.4 available, right? This is probably also going to be a problem. -greg |