Hi Ross,
Ross Walker wrote:
> Hi Ben,
>
>> I've noticed that parts of the AMBER compilation and testing create a
>> lot of files which are not taken care of by "make clean". I'm
>> especially
>> talking about the output files from many of the tests, and directories
>> such as bin/, include/ and lib/ together with all their contents.
>>
>> Is this a deliberate choice, or is it left over from somewhere, and
>> would people be happy if I began work to fix it (e.g., creation of
>> cleaning scripts)? It seems to me that, ideally, a "make clean" should
>> restore the cleaned directory to its original state, with the exception
>> of configuration files such as config.h and config_amber.h. But I
>> wouldn't be surprised to discover that there's a reason why things have
>> been done the way they have in AMBER. Thoughts?
>
> I second this - I would love it if the clean scripts returned things to the
> state that if you do a cvs update you do not get any question marks. Perhaps
> the one exception to this would be to leave the executables in the bin
> directory. Certainly the lib dir should get cleaned though.
>
> Note this should be done in a way that people can clean things individual
> sections. E.g. cd src/sander; make clean. cd test; make clean etc. I also
> think it would be useful if there was a global make clean - in $AMBERHOME.
> Or alternatively one in src and test that you do not need to run twice, once
> for AMBERTOOLS and once for AMBER. This is becoming more important since a
> lot of the source code is now actually shared between AMBER and AMBERTOOLS
> so it is not always clear where object files for one end and the other
> start.
>
> 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.
What I thought I might do - time permitting, of course - is to actually
set up a "make uninstall" which takes care of the top-level bin, include
and lib directories. This would be separate to the "make clean", which
would take care of only the builds within the src tree. I know that
"make uninstall" is fairly common, even if not yet universally observed.
Each program would have its own "make uninstall", and thus the common
"make uninstall" would simply invoke the individual "make uninstall"s,
perhaps with a "rm bin; rm lib; rm include" at the end.
Regarding name standardisation in the test directory, I honestly hadn't
given it much thought, since I saw that many of the tests do their own
renaming (e.g., you might have mdout.foo, mdout.bar and mdout.baz all in
the same directory, pertaining to slightly different variations of the
same category of test). It seemed easiest to me to just write a clean
script for each test to throw away those files created by a normal run
of that particular test. If I do standardise the names, though, which is
conventional: "mdout.foo", "foo.out", or whichever the cleaner-upper
decides?
Cheers,
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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Aug 21 2009 - 09:11:04 PDT