Hi,
The plan is not clear to me, so i'll cover some possible plans:
if AMBERHOME will be completely eliminated from every Amber file then
we don't need to validate it;
presumably users do not need to source amber.sh ?
else if AMBERHOME is only to be defined in amber.sh which users must source then
we need validation:
A. validation in configure to find a conflicting AMBERHOME.
B. validation in Makefiles to ensure AMBERHOME is defined.
end if
Note that we already have done A. and B. For A. see check_amberhome
in configure2. For B. see target is_amberhome_defined in some Makefiles:
is_amberhome_defined:
.(if [ -z "$(AMBERHOME)" ] ; then \
echo "Error: AMBERHOME should be defined or else some tests will fail !" ;\
exit 2 ;\
fi ;\
)
scott
On Mon, Feb 06, 2017 at 04:48:12PM -0500, Hai Nguyen wrote:
> thanks Scott. I will keep two points in mind.
>
> Just have a question regarding #2:
> What's your recommendation here?
>
> If user set the wrong AMBERHOME, raise error saying
> either unset AMBERHOME or correct it?
>
> My point of gradually eliminating AMBERHOME is to force the installation to
> use variables in config.h. For example. I added AMBER_SOURCE and
> AMBER_PREFIX to point to source code and install dir respectively. Those
> envs are set by configure script, not
> by users and they are only needed at compile time (and testing time).
>
> Ideally, user just need
>
> cd amber17
> ./configure gnu
> source amber.sh
> make install
>
> In my opinion, AMBERHOME is only helpful (now) for backward compatibility
> (e.g: for the tutorials in amber website).
>
> Hai
>
> On Mon, Feb 6, 2017 at 4:08 PM, Scott Brozell <sbrozell.rci.rutgers.edu>
> wrote:
>
> > Hi,
> >
> > As a way to encourage best practices, here are some comments:
> >
> > 1. Clarity - communicate effectively.
> >
> > commit ad2afeaf39e9a8ddc9b2f59a8583cbe2e633a78a
> > configure: users do not need to set AMBERHOME to install it
> >
> > This log leaves no doubt about intent.
> > Please write accurate logs because some actually do read the logs.
> >
> >
> > 2. Generality - validate user inputs.
> >
> > What the commit above did in practice was to disable the existing
> > user validation of AMBERHOME. We should try to support a broad range
> > of users which includes the dumb ones and the forgetful ones...
> >
> >
> > For more principles of programming, including some on testing, see
> >
> > .book{kernighan99,
> > author = "{Brian W. Kernighan and Rob Pike}",
> > title = "The Practice of Programming",
> > publisher = "Addison--Wesley",
> > address = "Reading, Mass.",
> > year = 1999 }
> >
> >
> > scott
> >
> > On Mon, Feb 06, 2017 at 02:19:27PM -0500, Hai Nguyen wrote:
> > > On Mon, Feb 6, 2017 at 2:12 PM, Scott Brozell <sbrozell.rci.rutgers.edu>
> > > > Just to set the record straight, I was not referring to --skip-python.
> > > > As i wrote in my post, an example is the commit regarding AMBERHOME;
> > > > that commit added this to configure:
> > > > export AMBERHOME=`pwd`
> > > >
> > > > Not testing this in an environment where AMBERHOME is undefined
> > > > is like adding feature x to program y and then not testing the
> > > > x y combination.
> > > >
> > > >
> > > Just make thing clear: My comment in $AMBERHOME/configure about no need
> > to
> > > set AMBERHOME is actually mis-leading. I only meant that user do not need
> > > to explicitly doing
> > >
> > > export AMBERHOME=`pwd` before running ./configure. (Of course he/shell
> > can
> > > still do that).
> > >
> > > but he/she still need to source amber.sh before "make install" (which
> > also
> > > setting AMBERHOME env).
> > >
> > > So basically AMBERHOME is never been undefined at install time. (that's
> > why
> > > I have never tested this).
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Feb 06 2017 - 17:00:03 PST
