Hi,
Jason said:
> I agree here. configure is now fairly robust to most MPIs. The Cray
So this thread may be a zombie, but i responded to your comments below.
On Sun, Jan 20, 2013 at 04:17:12PM -0500, Jason Swails wrote:
> On Sat, Jan 19, 2013 at 6:45 PM, Scott Brozell <sbrozell.rci.rutgers.edu>wrote:
> > 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
> > > > On Fri, Jan 18, 2013, Josh Berryman wrote:
> > > >
> > > > > 1) ./configure -mpi intel:
> > > > > Require that all the paths are set up: mpicc points to mpiicc, with
> > > > > 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).
Ok, i missed your main point. Here are some comments:
I do not frequently prepend AMBERHOME/bin.
I have been bitten by the Gaussian's "install" issue.
Over the years, say 20 of them, it has been common practice to
install some scientific software and prepend it to one's path.
So in my view prepending to ones path is in general not a bad
practice and the Gaussian's "install" issue is a Gaussian bug.
> > 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.).
I agree it may be easy to modify configure as you suggest.
And that gets configure closer to common practice.
But playing devil's advocate, each env. var. introduced is
another way for clueless users to shot themselves and another
thing we have to request to debug their broken build.
> 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?
Instead of requiring path changes to change versions of MPIs, compilers,
etc., one would have to move or delete mpif90/mpicc in this approach.
So this Might be an operational improvement but not an advance of
flexibility.
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Jan 20 2013 - 17:30:04 PST
