Hi, David:
Thanks for the valuable comments.
Excuse me, I changed my mail account (mk1g6g.yahoo.com.cn) to gmail at this
mailing list, so you may see a different sender name now.
I would like to coordinate with the Amber development team. But how could I
get contact with the team director or major code writer except via this
mailing list? Is there any mailing list for amber code developer?
Here is my comments on your concerns.
In the first place, I should say that the goal of using autotool is to
streamline the installation experiences to end user rather than minimize the
coding efforts of developers. It may be better seen as a good non-GUI
cross-platform installer. As a commercialized software package, user
friendly installer is a must.
Since I do not have access to the Amber9 source code, I have to use Amber8
as a platform to demostrate the autotool capability. When I have access to
Amber9, I think it will be not too hard to adapt to new configuration
themes. In addition, I would like to propose a new installation layout to
meet the mainstream installation standard if the team is interested.
The most important reason that I want to use autotool is to hide
(auto-detect the default value of) the various tuning knobs in the configure
script. For example, there are several compiler/architect combinations
switches, such as sgi_mips, sparc and etc. And the arch guess code in
current configure script is quite limited. Can we automatically discover
most of the values of the supported combinations for end users? Autotool is
good choice. The parallel library detection is another example. My idea is
to use autotool to auto-detect default values for end users and reserve the
knob handles to the desperated cases and those advanced users.
As for the developers, the autotool will not as straight forward as the
hand-written makefiles. However, it maybe lead to more cleaner and modular
codes. If not, the current configuration script would get more massed up
when Amber being ported to more platforms. A little off the point, BlueGene
or Cell are really interesting, if I have the chance, I would like to do the
migration works.
Frankly, autotool is overkill to the coder. Even a small change to one
makefile may lead to regenerate all makefiles of whole project. Although
there are some workarounds, they are not standard after all.
Alternatively, we may seperate the development workflow to two stages, code
writing stage and release building stage. The introdution of autotool is
well suited for the second stage.
On 10/19/05, David A. Case <case.scripps.edu> wrote:
>
>
> My comment: You might think about trying to coordinate this with the Amber
> development team, (although I have always been suspicious that autotools
> is
> overkill for what we need). The reason are these: first, unless the
> changes
> get propagated to lots of users, they won't help anybody but you (and you
> presumably already know how to configure Amber); second, the Amber 9
> configuration scheme has advanced a lot beyond that in Amber 8, so an
> autotool
> capability would have to meet some new requirements.
>
> As you know, Amber depends upon Fortran compilers, (which may be in
> unusual
> places) and external libraries like BLAS, MPI, etc. (ditto). Develpers
> need
> to be able to modify optimzation levels, and the whole scheme must be able
> to
> be modified for future environments in a straightforward manner. (Think
> about
> porting Amber to BlueGene/L, or to whatever the next "hot"
> high-performance
> machine is.) In the current scheme, all of this can be done by modifying a
> (somewhat-complex) shell script called "configure". If the configure
> script
> is to be constructed from autotools, we need to make sure that other
> deveopers
> can learn how to modify the results in a straightforward fashion.
>
> (This is not to say that the current configuration scheme doesn't need
> improvements. But I wonder if putting some effort into the current scheme
> might not pay better dividends than trying to convert both the configure
> script and lots of Makefiles over to autotools.)
>
> ...dac
>
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Wed Oct 19 2005 - 16:53:01 PDT
