[AMBER-Developers] code bloat in AmberTools?

From: case <case.biomaps.rutgers.edu>
Date: Sat, 22 Jan 2011 10:10:47 -0500

On Wed, Jan 19, 2011, Ross Walker wrote:
> With regards to the X Motif libraries the best approach is probably to have
> the configure script test if they are there and skip things if they are not.
> The alternative is too include the X Motif libraries in AMBER Tools and
> build them as part of the build process. I don't like this approach though.
> Lots of people have been doing it of late with NetCDF, Boost, Python etc and
> it is just leading to total bloat.

There are a variety of points here that need to be considered:

1. Download size is becomming an issue. Here are some current sizes:

     boost for mtkpp: 16 Mb
     boost for gleap: 29 Mb
     python: 70 Mb
     netcdf 18 Mb

    The current AmberTools tarball (*after* bzip) is 152 Mbytes, and we
have users on slow connections. The key size problems are in the test
cases, some of which are *huge*; but trimming code could also be a plus.

2. I am really more worried about code portability than bloat per se.
For the most part the complicated stuff (mpi, netcdf, boost, python)
actually compiles OK, and we would probably cause more grief by telling people
to go download these from other sources than by having a version that we know
works included. [In the past, the boost code in particular greatly limited
the number of compilers that could be used; I don't know if that is so true

However, we often want to compile (parts of Amber) on specialized machines that
don't conform to the Linux/Unix/Mac expectations for an environment. I think
it is pretty easy for an experienced person to do that, but we should continue
to make this as simple as we can.

3. We should have a discussion of Ross' point at the developers' meeting.


AMBER-Developers mailing list
Received on Sat Jan 22 2011 - 07:30:06 PST
Custom Search