Hi,
The underlying issue with most of these code improvements is
platform support. Despite the large platform exposure of the
Amber developer community, there are always problems on some weird
platform X discovered during testing, during the push for a release,
or after release by users.
The main tradeoff is thus large platform support versus easier
maintenance and mostly not major code improvements.
In my opinion the balance we have now is ok.
However, spring cleaning season is upon us.
No doubt there is deadwood, and it sometimes manifests itself with
preprocessor names associated with old platforms.
amber11/src/sander/ifdefs, which is probably in need of updating,
has ABSOFT_WINDOWS, CRAY_PVP, THIRDO as possible oldies-but-not-goodies
that 1 minute of browsing exposed.
Note that this cleanup should be considered a part of routine development
and maintenance as well as adding implicit none, documenting
[Enter a one-line description of subroutine bla here],
running the test suite, committing in a timely manner, etc.
In summary, be disciplined developers and contemplate:
what platforms do we want to support?
what platforms must we support?
Scott
On Fri, 27 Mar 2009, Joe Krahn wrote:
> David A. Case wrote:
>> On Thu, Mar 26, 2009, Joe Krahn wrote:
>>> At least for Gnu make, it is useful to use $(MAKE) instead of 'make', partly
>>> because it allows a parallel-make, giving much faster build times on
>> I thought Ross had already done this(?)
On Mar 2009, Ross wrote:
> ...mostly except for NAB...
>>> The reason for having _REAL_ is to allow single-precision builds.
>> But we don't *really* allow this, it just kind of looks like it. Since
>> So, my vote is to let this sleeping dog lie....
> If so, then why not replace _REAL_ with DOUBLE PRECISION and at least get rid
> of the dprec.h hack?
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Mar 29 2009 - 01:10:12 PDT
