From: Alan W. I. <ir...@be...> - 2006-11-27 22:38:42
|
On 2006-11-27 21:41+0100 Werner Smekal wrote: > 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. I hope he didn't mean that... :-) I want to keep the current scripting intact for the Unix side of everything since shell scripting is installed by default for Unix and most Unix developers understand it. OTOH, Tcl is not installed by default, and I am not sure that most Unix developers understand it. > >> >> 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. Well, those general hacking requirements sound like a showstopper for the windows bash idea. Too bad! It looks like we are back to a separate (please!) tcl scripting solution and the maintenance (as I said mostly irritating rather than difficult) that would go into that. However, I would advise you to steer clear of building your own tcl interpreter within the windows version of PLplot because of the additional maintenance load you would bear. I really think it is up to windows users to install their own tcl solutions (if they really want to try ctest or the install tree tests). Of course, you can advise them on the wiki that jim works great for this purpose if they don't have access to a full-blown Tcl. >> [...]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. If jim fails there are always python and perl and windows-only alternatives. Even if python or perl were ultimately chosen I would like those to be a separate (please!) windows-only solution because scripting is installed by default and well understood on Unix and python (and sometimes perl) are not. So forget the Unix side (which should remain intact as is) and go for a separate windows-only solution that you are most comfortable with. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |