[cctbxbb] Debian Package

[Richard Gildea]

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;f=debian/patches/0015-fix-cif-parser-to-work-with-antlr3c-3.2.patch

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 <nechols at lbl.gov> wrote:

> On Tue, Aug 7, 2012 at 11:19 AM, Radostan Riedel
> <raybuntu at googlemail.com> wrote:
> > But we don't want to overlook you and give some of our work back into
> 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
> cctbxbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20120807/4021708c/attachment.htm>