Hi Jason,
Okay I went ahead and cleaned up the AmberTools Makefile - also cleaned up the Amber cuda makefiles with .PHONY. Things are working as far as I can tell with the exception that the library clean target is not getting run between cuda_SPFP and cuda_DPFP - so cuda_DPFP ends up identical to cuda_SPFP. Here's what I have in the makefile right now:
$AMBERHOME/src/pmemd/src/Makefile
.NOTPARALLEL: cuda_serial cuda_parallel cuda_SPFP cuda_DPFP cuda_SPXP cuda_lib_clean pmemd.cuda_SPFP$(SFX) pmemd.cuda_DPFP$(SFX) pmemd.cuda_SPXP$(SFX)
.PHONY: cuda_serial cuda_SPFP cuda_DPFP cuda_SPXP cuda_lib_clean
#cuda_serial: configured_cuda cuda_SPFP cuda_DPFP cuda_SPXP
cuda_serial: configured_cuda cuda_SPFP cuda_DPFP
cuda_SPFP: cuda_lib_clean pmemd.cuda_SPFP$(SFX)
.( \
mv pmemd.cuda_SPFP$(SFX) $(BINDIR)/pmemd.cuda_SPFP$(SFX) ;\
cd $(BINDIR) ; ln -f -s pmemd.cuda_SPFP$(SFX) pmemd.cuda$(SFX);\
)
cuda_DPFP: cuda_lib_clean pmemd.cuda_DPFP$(SFX)
.( \
mv pmemd.cuda_DPFP$(SFX) $(BINDIR)/pmemd.cuda_DPFP$(SFX) ;\
)
cuda_SPXP: configured_cuda cuda_lib_clean pmemd.cuda_SPXP$(SFX)
.( \
mv pmemd.cuda_SPXP$(SFX) $(BINDIR)/pmemd.cuda_SPXP$(SFX) ;\
)
cuda_lib_clean:
$(MAKE) -C ./cuda clean
cuda_lib_clean only gets run once before the SPFP build.
If you have a moment to take a look at the master and see if you can figure out what is causing this still not to work it would be much appreciated. I am pulling my hair out with this right now.
All the best
Ross
On Feb 4, 2016, at 18:17, Jason Swails <jason.swails.gmail.com> wrote:
>
>
> 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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 04 2016 - 19:30:03 PST
