On Tue, Oct 23, 2012 at 08:43:36AM -0400, David A Case wrote:
> On Tue, Oct 23, 2012, Reinis Danne wrote:
> >
> > Working on Gentoo ebuild for AmberTools I ended up with several
> > patches which might be useful to include in AmberTools.
>
> Thanks for your suggestions, which we will look at, and probably incorportate
> some. Some are unlikely to gain acceptance from developers. In particular,
> we almost always want to see the results of all tests, even if some fail.
> With many hundreds of tests, many/most platforms have a few "failures", and
> and stopping (until they are fixed) is often not very helpful. I also think
> that for most users, the disadvantage of "make -j" for the tests (that the log
> files are not in order and might even be messed up) outweighs the speed
> advantages.
First, I think you missunderstood when the tests are stopped.
With the current patches all of the serial tests are run (I
haven't looked yet at MPI version) and then make exits with
non-zero exit code if any of the tests failed, which indicates
to the user that most likely it is not a good idea to proceed
with installation and using the software. It will just not
proceed to testing Amber if AmberTools tests are failing (which
is a feature you might or might not like).
Second, not wanting to run tests concurrently shouldn't
influence acceptance of particular patches in any way. The tests
are still run serially unless user explicitly invokes make test
with option -j.
I can't argue about others, but I care only that there are no
errors in the tests, so I want to run them as fast as possible,
and if I want to analize particular failures, they are still
there written in files. And of course if the output ordering is
important, run in serial (which still happens by default).
>
> Other fixes look quite helpful. I was not aware of arpack-ng, and will look
> into that. I don't understand what goes wrong if you hardcode the ucpp path:
> the whole point is to make sure that we get a consistent pre-processor
> behavior; at least in the old days, versions of cpp that might be lying around
> on a system could not be relied upon.
You can still give full path in configure and that exact
executable will be used. If the path is hardcoded in the
executable I have to change the source file (instead of
configure file) to point it to ucpp installation outside
AMBERHOME. In my case ucpp would be from the system install and
if it doesn't behave correctly it is a bug which have to be
fixed in ucpp.
In any case, I'm offering what I think might be useful (some are
more useful than others though), decision to use them or not is
up to developers.
Reinis
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Oct 23 2012 - 08:30:03 PDT
