Scott Brozell wrote:
> Hi,
>
> Sorry for the slow reply.
>
> On Fri, Aug 21, 2009 at 11:23:47AM -0400, case wrote:
>> On Fri, Aug 21, 2009, Ross Walker wrote:
>>> Note a lot of the issues with the make clean, especially in the test
>>> directory come from the fact that there is no longer and standard naming
>>> conventions for test cases. I think *.dif is still used everywhere but then
>>> we have people creating mdin files from the run scripts with random names,
>>> we have mdout.foo and foo.out, restart.bar and bar.rst etc etc. I think it
>>> makes more sense to take a big cup of coffee and have a pass through the
>>> entire test structure to standardize things before modifying the make file
>>> to include as many options as you can think of.
>
> b> On Fri, Aug 21, 2009, Ben wrote:
> b> Regarding name standardisation in the test directory, I honestly hadn't
> b> given it much thought, since I saw that many of the tests do their own
> b> renaming (e.g., you might have mdout.foo, mdout.bar and mdout.baz all in
> b> the same directory, pertaining to slightly different variations of the
> b> same category of test). It seemed easiest to me to just write a clean
> b> script for each test to throw away those files created by a normal run
> b> of that particular test. If I do standardise the names, though, which is
> b> conventional: "mdout.foo", "foo.out", or whichever the cleaner-upper
> b> decides?
>
>> An alternative: avoid the big cup of coffee, so that you are nice and calm
>> when attempting this task!
>>
>> Once idea: consider the following patch to dacdif:
>>
>> RCS file: /home/amber_cvs/cvsroot/amber11/test/dacdif,v
>> retrieving revision 10.1
>> diff -r10.1 dacdif
>> 260c260
>> < /bin/rm $path.$dif_ext
>> ---
>>> /bin/rm $path.$dif_ext $path
>> This has the effect that if a test PASSES, the new output is removed (which
>> should be OK since it is essentially the same as the saved file.) If the test
>> FAILS, then the (bad) output file is still around for examination.
>>
>> Ideally, the test cases individually should clean up after themselves. That
>> is, it should not be necessary to have a separate script to do this. But this
>> is grunt work, as is Ross' suggestion....
>
> I second Dave's comments.
> Everyone should take note of
>> Ideally, the test cases individually should clean up after themselves.
>
> I started a standardisation effort long ago when i did a lot of grunting.
> In my model the main output file was not removed; so changing dacdif would
> produce pristine cleanliness for those tests like
> dhfr/Run.dhfr
> I'll probably commit that soon.
>
> I think changing dacdif and incrementally fixing test scripts to
> follow a template like dhfr/Run.dhfr is enough grunting.
> But if Tarzan is your hero and Jane's away on vacation then the right roar
> is to redo all tests to use make with suffix rules (i don't think
> pattern matching rules would be necessary; in fact since sander default
> file names exist, you might go pretty far without even suffix rules,
> but suffix rules are still probably better).
>
> Aside from the roaring and grunting the main drawback is somewhat
> less transparency for those not willing to invest just a little
> more time; but then it's these ignorant masses that have created
> the mess by writing test cases from scratch without using a template;
> so the bar shouldnt be set tooo low; ahhh, foooy.
>
>
> Why waste time with coffee, go for the better bean:
> http://www.greenandblacks.com/us/what-we-make/bars/dark-85.html
>
OK, to get the ball rolling with the "Makefile" idea, I created a simple
makefile in the test/elsize directory. Why this one, you may ask?
Largely because it's small and almost trivial, so I thought it was a
useful proof of concept. I've also attached the same Makefile as an
attachment to this email for your convenience.
At present, this Makefile is *not* called automatically. The master
Makefile still runs Run.elsize. The call to "Run.elsize" there should be
replaceable with a "cd elsize && $(MAKE) test".
Similarly, I've set up a make clean, so a make clean at the top level
should be able to go into the same directory: "cd elsize && $(MAKE) clean".
At the moment, I've set it up so "make test" automatically finishes off
with "make clean", assuming the commands preceding "make clean" (i.e.,
the main executable and dacdif) both complete successfully. This use of
"make clean" is, of course, not necessary at the moment, what with
dacdif cleaning up after itself. I put it in there as an example of
"this is what it might look like if we decide to remove that function
from dacdif and put it in Makefiles instead". If dacdif's self-cleaning
function works, I'm happy enough to leave things as they are, though.
What do people think - go ahead with makefiles (a bit at a time, so as
to reduce grunting), and if so, is the type of makefile I've written OK?
Thanks,
Ben
--
Benjamin P. Roberts
Postdoctoral Research Associate
Quantum Theory Project
University of Florida
2301 New Physics Building #92
PO Box 118435
Gainesville FL 32611-8435
USA
Phone: +1 352 392 6712
Cell: +1 352 222 3677
Member of the Royal Australian Chemical Institute
and of the American Chemical Society
include $(AMBERHOME)/src/config.h
dacdif = $(AMBERHOME)/test/dacdif
exe = $(BINDIR)/elsize
input = trxox.2.4ns.pqr
output = elsize_out.trxox
save = $(output).save
test:
$(exe) $(input) > $(output)
$(dacdif) $(output) $(save)
$(MAKE) clean
.PHONY: clean
clean:
-rm -rf $(output)
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Sep 29 2009 - 13:30:02 PDT
