Re: [cctbxbb] Debian Package

Here are the patches to the ANTLR 3.4 C runtime to which I referred in my previous email: http://cctbx.svn.sourceforge.net/viewvc/cctbx?view=revision&revision=14622 With this patch we saw approximately 30% reduction in memory usage during parsing of large CIF files. Cheers, Richard On 7 August 2012 14:43, Richard Gildea wrote:

Hi Radostan,

I think the integration with distutils would be A Good Thing to increase accessibility of the cctbx to users.

One addition to Nat's comments:

I noticed this commit with the log "fix cif parser to work with antlr3c 3.2":

http://anonscm.debian.org/gitweb/?p=debian-science/packages/cctbx.git;a=blob...

This is essentially a revert of the cctbx svn revision 14621 ("ucif: upgrade to antlr3.4"):

http://cctbx.svn.sourceforge.net/viewvc/cctbx/trunk/ucif/parser.h?r1=14583&r2=14621

The ANTLR C runtime changed its interface slightly between 3.2 and 3.4, hence the changes in revision 14621. From what I remember it isn't trivial to determine the ANTLR runtime version at compile time which was why we made no attempt to support both versions of the runtime. If you wish to be able to compile against 3.2 in addition to 3.4 we will need to figure out how to determine the runtime version. We also use a slightly modified version of the ANTLR C runtime in order to obtain savings on memory (particularly when reading large ribosome data files).

Cheers,

Richard

On 7 August 2012 14:27, Nathaniel Echols wrote:

...

...

But we don't want to overlook you and give some of our work back into

On Tue, Aug 7, 2012 at 11:19 AM, Radostan Riedel wrote: the main

...

project.

We have a few patches to give back upstream that would really help us and hopefully help to increase the cctbx user community.

Thanks for investing your time in this. We agree that it would be very helpful in making CCTBX more accessible - our main concern is that any changes not impact the existing projects which depend on it (Phenix, Olex2, CCP4, LABELIT, etc.), including the ability to support these on all current platforms*. Within this constraint, in principle we're happy to accept any changes that you feel would be worth incorporating. This should be done slowly and incrementally; conservative modifications that don't modify the default behavior should go first, but I suspect you will eventually need access to our testing systems in Berkeley in order to run tests. Obviously you should be working from the trunk when you do this. I noticed that you've also modified the ccp4io_adaptbx tree, which is kept on our local SVN (for reasons that are obscure to me); we can deal with that later**.

A random aside: we will be switching to building against the Boost release branch very soon. Not sure if this affects you or not.

...

But if we can count on the shlib versioning as mentioned here[5] it would help us and other developers a lot. Libtool should be available on most systems, works with common compilers and it provides the quasi standard for versioning shlibs.

This is one point that came up in discussion here: how will this impact Mac? Apple's libtool appears to be an entirely different beast. Or will your changes only affect Linux right now?

-Nat

(* At the moment, this means Fedora 3 or newer using gcc [and Intel's compiler, I guess, but we're less firm on this]; Mac OS 10.4 or later using Xcode 2.4 or later, including both PPC and Intel; and Windows XP or newer using VC++ 8.0 or newer. And Python 2.4-2.7 in any case.) (** It looks like you're building against gpp4 instead of the ccp4 libs - or is it in addition to ccp4? I suspect this may be problematic in the long term.) _______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb