Re: [Plplot-devel] convenient windows developing

2006-11-27 Thread Werner Smekal
Hi Arjen,

 They won't. Windows uses DOS batchfiles and I know there is a command 
 language
 slightly more powerful than that, which I have never used, but it is 
 completely
 incompatible with UNIX shell scripts.

As written before, it is possible, but with problems. With Vista also a 
new powershell was developed also for windows xp, but I don't want to 
learn another syntax - and as you said not nearly compatible to unix 
scripts  but super powerful with objects and classes 

 I would opt for Tcl :). Or Jim, a very lean implementation of Tcl, which 
 I  used
 already for the old build system. This is lean enough to distribute 
 along with the
 PLplot source, so that would make testing independent of the presence of 
 Python,
 Perl or Tcl or whatever on the system.

Tcl is also not commonly used in the Windows world, I think, but if jim 
is distributed with the plplot source and compiles with most of the 
compilers used, this should also be okay, I think.

Regards,
Werner

-- 
Dipl. Ing. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: [EMAIL PROTECTED]
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
+43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

-
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


Re: [Plplot-devel] convenient windows developing

2006-11-27 Thread Andrew Ross
On Mon, Nov 27, 2006 at 09:15:22AM +0100, Arjen Markus wrote:
 Werner Smekal wrote:
 
 
 So, long story short, ctest works now, with small problems though. I 
 wasn't actually successful running the plplot-test.sh script in the 
 examples folder of the install directory (share/plplot-5.7.1), but this 
 would need also minor tweaking.
 
 Arjen, would you willing to also try to install this to make ctest work?
 
   
 
 Yes, I will look into this part. Pity about the possibility of running 
 shell scripts under
 Windows, but such is life.

Sorry to pop in at the end of this discussion. When I first implemented
the ctest stuff I wondered about doing away with the scripts and doing
all the work in ctest. 

Advantages:
Should be more platform independent.
You would be able to see at a glance precisely which tests failed rather
than just knowing one of the tests for a given language failed. 

Disadvantages:
More work for me in the first instance.
We want the scripts anyway for installing in the examples tree so users
can test the examples easily.

The scripts are not terribly sophisticated on the whole. The most
important requirement is just to set the right paths for libraries etc.
Perhaps a batch file will do. At least we know that will run on every
windows system then.

Andrew

-
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


Re: [Plplot-devel] convenient windows developing

2006-11-27 Thread Werner Smekal
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