On Thu, Feb 4, 2016 at 8:20 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
>
> Which looks to me like it echoes that no CUDA-enable components are in
> AmberTools and then goes and calls Make cuda in $AMBERHOME/src/ - this then
> goes and builds cuda but then the install target then also goes and calls
> $AMBERHOME/src/ make install after the AMBERTools build completes. So it
> looks like this is why everything gets built twice - and indeed I think
> this has been like this and we have been doing it for a while. :-(
>
Hmm... yep. I had to go back through the git history to figure out what
happened. I originally added a version of those lines (Dave simplified my
original rule) back in commit 378e3367b3bdcd678b24e64b2696cb7a64f5eb91 --
this time predates the existence of $AMBERHOME/Makefile and
$AMBERHOME/configure (when you had to run configure and make inside
$AMBERHOME/AmberTools/src). It was my way of making it so that "make
install" automatically built both Amber and AmberTools components if you
had Amber.
When we added top-level Makefile and configure scripts inside $AMBERHOME,
that task was moved to $AMBERHOME/Makefile, but the original rules were
never removed from the AmberTools Makefile. Same thing for parallel and
serial.
However, things were never really getting built twice. The reason is due
to the way that the dependencies were set up and the fact that no pair of
dependencies ever shared a file (as it really should be). So yes, "make
install" was being run twice, but the second incantation was always a
no-op, since all dependencies were satisfied for every rule, so there was
never anything for make to do. Had the builds been happening twice, I
definitely would have noticed and fixed it long ago.
Parallel make *was* wonky in the past for CUDA, with the same target
getting built by different threads so that there was a very large
duplication of efforts, but the root cause was the use of a rule comprised
of multiple tokens which I fixed in commit
6ccbb55f913f4fcbc232294b3062b86f6c61a677
(after I had been annoyed one too many times by that behavior).
So surely those
>
> -(cd ../../src && $(MAKE) cuda )
> etc
>
> lines should not be there in the AmberTools/src/Makefile no?
>
Correct. And they should be removed for every install target in
$AMBERHOME/AmberTools/src/Makefile. In the interest of not clashing with
the changes you're working on
now, I'll hold off on changing those until you get your commits in. If
you want to clean that up while you're doing whatever you're doing that'd
be fine too.
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 04 2016 - 18:30:03 PST
