On Sat, Jan 19, 2013 at 6:45 PM, Scott Brozell <sbrozell.rci.rutgers.edu>wrote:
> Hi,
>
> On Fri, Jan 18, 2013 at 01:49:31PM -0500, Jason Swails wrote:
> > On Fri, Jan 18, 2013 at 10:55 AM, David A Case <case.biomaps.rutgers.edu
> >wrote:
> > > On Fri, Jan 18, 2013, Josh Berryman wrote:
> > >
> > > > Yes. It seems like there are two separate use-cases, which is
> leading
> > > > configure to have a bit of an inconsistent approach
> > > >
> > > >
> > > > 1) ./configure -mpi intel:
> > > > Require that all the paths are set up: mpicc points to mpiicc, with
> all
> > > > libs and paths set up correctly, and mpiicc pointing to icc. This is
> > >
> > > For me, mpicc/mpif90 are always in $AMBERHOME/bin, but I've not
> > > been able to ever convince anyone else that this is a desirable option.
> >
> > The only reason I don't suggest this is because then PATH ordering
> becomes
> > an issue. This is one of the biggest shortcomings of our configure
> script,
> > IMO -- to change versions of MPIs, compilers, etc., you have to change
> your
> > PATH environment so `which <thing>` will give you the right version of
> > <thing>. I also don't like the idea of requiring AMBERHOME/bin to be
> > prepended to the PATH (I'm not singling out Amber here), since it can
> > introduce hard-to-isolate bugs (Gaussian's "install" program caused me
> > hours of grief because of this).
> >
> > I think we should expand the flexibility of choosing compilers that are
> > _not_ the head of the PATH.
>
> There are simple solutions for reordering one's path
> (eg, learn some trivial shell commands, write some easy shell scripts,
> or write some easy modules for one of the many modules packages).
>
The point wasn't necessarily that it's hard to reorder an environment
variable to get the behavior you want -- the point is that prepending
AMBERHOME/bin to $PATH is borderline bad practice, in my opinion, and is
certainly not something we should require of users. Using the Amber-built
MPI installation requires exactly that (unless there is either no system
MPI or it's not in a system-critical location, like /usr/bin or
/usr/local/bin).
> So I do not think that we should expand flexibility unless it can be
> done with a simpler configure while maintaining ease of use for
> Amber users(installers).
>
The only changes I ever make to the build process are those that I think
will make it easier for the users (whether my thinks are right is
debatable, of course). I think it's fairly trivial to get configure to
obey MPI_HOME (and specify a full path to mpif90/mpicc inside config.h,
etc.) or other common environment variables (e.g., CC, FC, F90, CFLAGS,
FFLAGS, etc.).
In fact, why not even look for mpif90/mpicc inside $AMBERHOME first, so
that if users _do_ use configure_mpich2 or configure_openmpi, that is
always the MPI that Amber uses? Is there any reason that users would have
those wrappers in $AMBERHOME/bin and NOT want to use them? Why make them
jump through the extra hoops of path ordering, when that could come back to
bite them in the end?
All the best,
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Jan 20 2013 - 13:30:03 PST
