On Wed, Feb 15, 2012 at 8:09 AM, David A Case <case.biomaps.rutgers.edu>wrote:
> On Tue, Feb 14, 2012, B. Lachele Foley wrote:
> >
> > Long time ago,
> > configure mostly just made config.h files. Once I got one that worked,
> > I would copy it to "config.h_serial_ia64_mpi" or whatever. Then, if I
> > had to recompile for some reason, I would just copy over the appropriate
> > config file to config.h to build serial or parallel. I assume your
> > statement means this is no longer possible?
>
Like Dave says, this is certainly possible, but it's not what I thought you
were advocating. I thought you wanted to enable both a parallel build
_and_ a serial build within the same config.h file. This approach is what
I said would require reworking (since several places make an assumption
that a config.h file _either_ specifies a parallel or a serial build). I
think it would be straightforward to change, but we all know how
straightforward such things really are.
I agree with the rest of Dave's comments below.
>
> This is certainly possible, but re-running configure is safer, even though
> it
> takes a minute or two to do. First, the configure script runs "make
> clean",
> which is generally needed if you swap config.h files. [The "make clean"
> step
> is something even experienced people often forget to do.] Second, if you
> are on
> the development tree, the contents of the config.h file may have changed
> since
> the time when you last ran it. So just pointing to an old config.h file
> might
> cause errors.
>
> > cd $AMBERHOME
> > ./configure gnu && make install
> > ./configure -mpi gnu && make install
> add: ./configure -cuda gnu && make install
> > [./configure -mpi -cuda gnu && make install]
> > make test.serial
> > make test.cuda
> > export DO_PARALLEL=blah && make test.parallel && make test.cuda_parallel
> > export DO_PARALLEL=blah8 && make test.parallel
>
> I think the above will work, but I don't recommend it. The cuda stuff is
> so
> distinct from the rest of the code that I think it should be installed and
> tested as a separate step, if for no other reason than the fact that you
> *really* want to be paying attention to any errors that might arise.
>
This is actually one issue I have with the current build setup. The way
Amber is conditionally installed is this rule in the Makefile:
install:
cd AmberTools/src && $(MAKE) install
-(cd src && $(MAKE) install)
All this does is provide a return value of 0 for failed Amber builds if I
understand correctly. The goal of this is to ignore the error "no
Makefile". However, if there is a build error with pmemd.cuda (or any
other Amber step), this will also return a value of 0, which makes it hard
to catch errors in scripts. Should we consider reworking this to actually
bomb out with an error?
Regarding your comment, though, I actually draw the divide between building
and testing. I'll build everything, make sure there were no problems, and
then test everything, and make sure the tests pass. I guess I don't quite
see the distinction between -cuda and, say, -mpi. As long as people pay
attention to the different build and test steps, I don't see how the order
matters, really.
All the best,
Jason
> ....dac
>
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
--
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 Wed Feb 15 2012 - 08:30:02 PST
