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":
This is essentially a revert of the cctbx svn revision 14621 ("ucif: upgrade to antlr3.4"):
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@lbl.gov> wrote:
On Tue, Aug 7, 2012 at 11:19 AM, Radostan Riedel
<
raybuntu@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.
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.)