Hi,
Hmm... It's interesting [...]
1) It adds parallel maintenance that Werner and Arjen have to apply to
the jim scripts any time there is a change to plplot-test.sh and the
other test*.sh scripts. This is all fairly trivial stuff (adding new
examples, finding better ways to configure the tests), but there is a fair
amount of churn, and it will be irritating to keep the two systems in sync.
2) There is also a maintenance burden for jim itself. Werner and Arjen have
to keep track of new jim releases, make judgement calls about the stability of
those releases, and decide when to deploy them into the PLplot code base.
The first of these reservations also applies to all other parallel scripting
systems (with python, perl, or whatever) which is why my opinion _now_ is we
should reject all of them. I only brought up the idea of parallel scripts
originally because I was under the impression no bash solutions were
available for windows, but it appears that such solutions exist. In fact,
Werner was able to get all but the java ctests passed with the windows bash
solution he found, and I doubt a solution is far away in that case.
I think, Arjen ment that we replace the sh-scripts with jim/tcl-scripts.
So for Linux, we don't need to compile jim, since tcl might be available
most of the times, and for Windows we use jim. So this might be a good
solution.
It appears the only downside to the windows bash solution is our windows
developers and users will need to independently install bash if they want to
use ctest and/or the install-tree plplot-test.sh tests. I doubt installing
a windows bash is going to be a difficult burden for Arjen or any other
windows developer that wants to contribute to PLplot since Werner has
already been successful at this, and almost by definition our developers are
good at installing PLplot dependencies. That leaves only the question of
our users. To make life easier for them, I think we should put together a
test to look for bash. If that test fails we should give the appropriate
warning message, force BUILD_TEST to OFF, and not configure or install
plplot-test.sh and the test*.sh scripts. Also, Werner should expand our
wiki a bit more giving a reference to windows bash and perhaps a sentence or
two about how to install it if that is not obvious.
I can do that (the wiki stuff), but have to mention, that the bash is
really not a good solution in the moment. e.g. cmake doesn't like sh.exe
in the path if I use MinGW/CLI combination, I have to rename it, run
cmake, rename sh again to run the tests. And then we would need still
some tweaking - it works far from perfect in the moment, and all tweaks
are actually hacks, since you always need to program around the fact,
that bash isn't actually meant to be there.
With those changes it should be straightforward for our windows users to
install bash, but if they choose not to do so, all that will happen is they
will receive a CMake warning and the ctest functionality will be missing and
install tree tests not available. So it will be exactly like any other
component of PLplot. If you want a particular PLplot component you have to
pay the price of installing the relevant software.
In sum, I have given my reasons why I prefer a uniform bash solution for all
platforms (especially since it apparently already works on bare windows
except for one minor Java issue). However, if the windows developers still
prefer the jim/tcl alternative (and are willing to develop it and more
importantly maintain it), I will go along since windows developers know
a lot more about windows than I do. :-)
We may should do some test first, if the jim solution is really the best
one, since we might run into the same trouble as with bash - don't know
how good tcl/jim is with the filenames.
Werner
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel