On 07/12/2011 01:02 PM, Terry Lang wrote:

         I use Chimera as a back end library for a bunch of my code.  I 
occasionally run into a function that an external library, scipy for 
example, has already implemented.  I have found the chimera flag that 
allows me to import python libraries for use.  However, because numpy is 
already distributed with Chimera, importing libraries that depend on 
numpy is almost _impossible_.  We run into a variety of version and 
compiler issues that are very difficult to work around.  Would it be 
possible to get more transparent documentation on how the numpy library 
is compiled and when it will be upgraded in a particular release?  
(NOTE:  We actually have this problem right now, so even an email with a 
description of the current nightly build set up would be SUPER helpful!)

So as you can tell, it's has not been a priority for chimera to be binary compatible with other software packages. And if you are installing your own Python packages to work with chimera, it is much easier to install them with chimera's Python into chimera's Python library (using chimera --noguil --script "setup.py ...") and use "chimera --nogui" to run scripts that use both chimera and other packages. Python packages, that have C code in them, should work, but ones that have C++ and Fortran code might not work.

numpy is updated on an ad hoc basis. We are generally conservative about updating it, but it can be updated for any reason (bug fixes, new version of Python needs new version, some other foreign package needs a newer version, etc.). And that can be said for any of the 30+ foreign software packages that are included with chimera. In the near term, I don't anticipate any updates unless we get requests for them (hint), except possibly for updating Python to the latest 2.7 version. The version numbers of the foreign packages are found in http://plato.cgl.ucsf.edu/trac/chimera/browser/trunk/mk/foreign.make, except for Python, Tcl/Tk, Tix, and Togl, which are in http://plato.cgl.ucsf.edu/trac/chimera/browser/trunk/mk/config.make. And configuration options for the foreign packages are in the per-package GNUmakefile in http://plato.cgl.ucsf.edu/trac/chimera/browser/trunk/foreign/.

The compiler flags for various platforms are found in http://plato.cgl.ucsf.edu/trac/chimera/browser/trunk/mk/os.make. The compiler versions used are not documented and may change. That said, on Windows, we use Microsoft Visual Studio 2008 because that is what the python.org version uses. On Mac OS X we use the standard compiler for the OS version, so the 32-bit version is built on Mac OS X 10.5.8 with Xcode 3.1.2 and the 64-bit version on Mac OS X 10.6 with Xcode 3.2.6. And then there's Linux. There are so many different versions of Linux that we build on a lowest common denominator system to get the forward-compatibility advantage of linking with an older C runtime. Currently, we are building 32-bit Linux binaries on a Debian 4 system with gcc 4.1.2 and plan to move the 64-bit builds to a Debian 4 64-bit system, but currently build on Red Hat Enterprise Linux 5.6 system with gcc 4.2.3. I don't see us changing from Debian 4 for a long time, but we might update our version of gcc to get C++0x features and other improvements -- no timetable for that though.

Our nightly build setup checks out a fresh copy of chimera on each platform every evening and then compiles everything and builds a chimera installer. The "mother" process waits for each build to complete and decides if the build was a success if the installer was built or not. Then the successful builds are added to the web site. The identical mechanism is used to build releases by adding an argument saying what kind of release it is. For the gory details, start with http://plato.cgl.ucsf.edu/trac/chimera/browser/trunk/tools/build_chimera.

HTH,

Greg