From: Werner S. <sm...@ia...> - 2006-11-24 21:34:42
|
Hi, today I managed to make plplot work together with Java on Windows. It wasn't that hard actually, if I only would know Java ;). Anywa, here is the cookbook: * Download J2SE(TM) Development Kit 5.0 Update 9 from http://java.sun.com/javase/downloads/index.jsp * Install package (Demos, source not needed, jre only if not installed already) * cmake finds java, except jni.h - you need to set environment variable: @set JAVADIR=C:\Program Files\Java\jdk1.5.0_09 @set CMAKE_INCLUDE_PATH=%JAVADIR%\include cmake doesn't need java in the path, but if you want to run the examples you might also need @set PATH=%JAVADIR%\bin;%PATH% * line 76 of java.cmake needs to be changed to set(PLPLOTJAVAC_WRAP_DLL plplotjavac_wrap${CMAKE_SHARED_LIBRARY_SUFFIX}) (already cvsed), Alan please check and tweak commentary * cmake should now find Java and compile everything (if you have swig installed as explained in earlier email) * you need to run "nmake install" after "nmake" so that java wrapper dll is in right place * if you have set -DBUILD_TEST=ON as cmake option you can test java examples with cd examples/java java -cp plplot.jar plplot.examples.x08 you also need to copy all needed dlls and font files in examples/java That's it. Straightforward (at least for windows ;). Another thing to tick off. Regards, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2006-11-24 23:57:25
|
On 2006-11-24 22:34+0100 Werner Smekal wrote: > Hi, > > today I managed to make plplot work together with Java on Windows. It > wasn't that hard actually, if I only would know Java ;). Good work, Werner! > * line 76 of java.cmake needs to be changed to > set(PLPLOTJAVAC_WRAP_DLL plplotjavac_wrap${CMAKE_SHARED_LIBRARY_SUFFIX}) > (already cvsed), Alan please check and tweak commentary This change works fine on Linux, and I expect it should work fine on Mac OS X as well. I have changed the commentary accordingly. Werner, to momentarily change topic to the Python interface generated by swig, I just discovered Numeric is available for windows users at http://sourceforge.net/project/showfiles.php?group_id=1369. Do you want to give it a try to see if that solves the remaining python issues? Werner, I assume you will be updating http://www.miscdebris.net/plplot_wiki/index.php?title=Overview_of_the_status_on_Windows soon to reflect all the additional PLplot features (now java and hopefully python soon) that are accessible from windows. Hazen, your release announcement should point to that website so our windows users who are trying out the new release have a clear idea of all the additional PLplot features accessible to them with our new CBS. 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 __________________________ |
From: Werner S. <sm...@ia...> - 2006-11-25 21:47:51
|
Hi, I also managed to make python bindings work on windows, at least for the MinGW compiler. How did I get there: * Download and install Python 2.4.4 ! (not 2.5) from http://www.python.org/ftp/python/2.4.4/python-2.4.4.msi * Download and install the old Numeric package Numeric-24.2.win32-py2.4.exe from http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=1351 The numeric package is not available for 2.5 * Than, as usual we need to set some variables: set PYTHONDIR=C:\DevZone\Python24 set PATH=%PYTHONDIR%;%PATH% set CMAKE_INCLUDE_PATH=%PYTHONDIR%\Lib\site-packages\Numeric\Numeric_headers\Numeric * Cmake should than find everything and turn python bindings on, if SWIG is installed and set up correctly. * Don't forget to have -DBUILD_SHARED_LIBS=ON and -DBUILD_TEST=ON * compile with mingw32-make * cd examples\python * if you run "python pythondemos.py" we get an error message Traceback (most recent call last): File "pythondemos.py", line 28, in ? from plplot import * File "C:/DevZone/plplot/bindings/python\plplot.py", line 20, in ? from plplotc import * File "C:/DevZone/plplot/buildmingw/bindings/python\plplotc.py", line 5, in ? import _plplotc ImportError: No module named _plplotc * If I copy the dll _plplotcmodule.dll from bindings/python I get the same error message. After I rename this dll to _plplotc.dll I get further and also need to copy other dlls (plplot.dll, etc.) and font files: "python pythondemos.py" works. * So this is also a quite success here, though why is this dll called _plplotcmodule.dll and not _plplotc.dll as python wants it to be called? Has someone some ideas? On MSVC/nmake it's the same procedure, but we get soon into trouble: Linking C shared module _plplotcmodule.dll LINK : fatal error LNK1104: cannot open file 'python24_d.lib' NMAKE : fatal error U1077: '"C:\Programme\Microsoft Visual Studio 8\VC\BIN\link.EXE"' : return code '0x450' Stop. I searched the whole plplot tree where we would set python24_d.lib, but I couldn't find anything like that. Cmake looks for this library but can't find it and sets the variables accordingly. And the makefiles for nmake are only temporary, so I can't check them :(. No idea, where the problem is here. Any ideas? Anyway, python is also "working" here in Windows. Regards, Werner PS: Thanks for the hint with the Numeric library. Alan W. Irwin wrote: > On 2006-11-24 22:34+0100 Werner Smekal wrote: > >> Hi, >> >> today I managed to make plplot work together with Java on Windows. It >> wasn't that hard actually, if I only would know Java ;). > > Good work, Werner! > >> * line 76 of java.cmake needs to be changed to >> set(PLPLOTJAVAC_WRAP_DLL plplotjavac_wrap${CMAKE_SHARED_LIBRARY_SUFFIX}) >> (already cvsed), Alan please check and tweak commentary > > This change works fine on Linux, and I expect it should work fine on Mac OS > X as well. I have changed the commentary accordingly. > > Werner, to momentarily change topic to the Python interface generated by > swig, I just discovered Numeric is available for windows users at > http://sourceforge.net/project/showfiles.php?group_id=1369. Do you want to > give it a try to see if that solves the remaining python issues? > > Werner, I assume you will be updating > http://www.miscdebris.net/plplot_wiki/index.php?title=Overview_of_the_status_on_Windows > soon to reflect all the additional PLplot features (now java and hopefully > python soon) that are accessible from windows. > > Hazen, your release announcement should point to that website so our windows > users who are trying out the new release have a clear idea of all the > additional PLplot features accessible to them with our new CBS. > > 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 > <__________________________ > > ------------------------------------------------------------------------- > 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.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Arjen M. <arj...@wl...> - 2006-11-26 09:14:48
|
> > On MSVC/nmake it's the same procedure, but we get soon into trouble: > Linking C shared module _plplotcmodule.dll > LINK : fatal error LNK1104: cannot open file 'python24_d.lib' > NMAKE : fatal error U1077: '"C:\Programme\Microsoft Visual Studio > 8\VC\BIN\link.EXE"' : return code '0x450' > Stop. > I searched the whole plplot tree where we would set python24_d.lib, but > I couldn't find anything like that. Cmake looks for this library but > can't find it and sets the variables accordingly. And the makefiles for > nmake are only temporary, so I can't check them :(. No idea, where the > problem is here. Any ideas? Hi Werner, if you use the --debug-trycompile flag, CMake will not remove the intermediate files. I do not know whether that is enough in your case, but it might help identifying where things are going wrong. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-11-26 10:04:25
|
Hi, I just committed a small change to plplot which should make life for windows developing easier (thanks for the hint, Alan): In CMakeLists.txt of the plplot main directory I added if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN) SET(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll) endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN) If we have shared libraries, Windows but not cygwin, all created libraries go into the dll directory. If you set PATH=path_to_plplot_build_dir\dll;%PATH% and set PLPLOT_LIB=path_to_plplot_dir\data all examples run without further copying of dlls, fonts, maps, etc. Both variables could be set in a batch file, which you run at CLI startup. Arjen, could you please check if this also works for you? Do you also need other stuff (exes?) to be copied or so? Regards, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2006-11-26 16:31:17
|
On 2006-11-26 11:04+0100 Werner Smekal wrote: > Hi, > > I just committed a small change to plplot which should make life for > windows developing easier (thanks for the hint, Alan): To summarize the effect of LIBRARY_OUTPUT_PATH, it collects all built libraries in one directory in the build tree which makes life much easier for windows developers to do their testing. (Of course, this is not needed for Unix and friends because cmake automatically makes build-tree rpath adjustments on Unix systems that takes care of all of this.) This build-tree change is a nice first step toward getting ctest working on windows. Of course, the problem still remains that the current ctest uses the shell scripts plplot-test.sh and test*.sh, and I assume (but correct me if I am wrong) those scripts will not work on bare windows. I am completely unfamiliar with the windows scripting constraints, but if there is no easy way to modify those scripts so they will also work on windows, then perhaps we should use the equivalent of those scripts in python or perl for the windows case? (I mentioned python first because I understand it and don't understand perl, but if the windows developers are more familiar with perl, that is the scripting language they should probably use.) This build-tree enhancement for windows developers is great, and I look forward to ctest eventually working for windows as a result, but it leads to the question of whether the equivalent of "make install" is supported on windows. I hope it is since "make install" collects all essential data and builds in a convenient and compact way for the user. If the equivalent of make install is supported, then you should check whether you have to modify all the INSTALL commands for the windows case to be consistent with the new build-tree location of libraries or whether cmake automatically knows what to do when LIBRARY_OUTPUT_PATH is set. 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 __________________________ |
From: Werner S. <sm...@ia...> - 2006-11-27 08:01:25
|
Hi Alan, > This build-tree change is a nice first step toward getting ctest working on > windows. Of course, the problem still remains that the current ctest uses > the shell scripts plplot-test.sh and test*.sh, and I assume (but correct me > if I am wrong) those scripts will not work on bare windows. No, I just was able to make them work. There are some bash-ports available (apart from cygwin, msys), but the problem here is (also see below), that you always run into problems sooner or later regarding filenames and so on. I was always looking for a bash I can use in Windows, but after a long series of failings, I came to the conclusion, that it is better to always use the native tools of the OS you are working on. Anyway, one exception are the GNUWin32 Tools you can find here: gnuwin32.sf.net . They provide ports of various gnu tools, and they did a good job, they just work also in the Windows CLI without problems, and regardless if you use \ or / or whatever. I think for the test scripts you need at least the core utils and sed (on the gnuwin32 homepage click left packages). Just download the binary package and the dependency package as zips and unzip them somewhere (e.g. C:\GNUWin32) and add the path to the environment variable (set PATH=C:\GNUWin32\bin;%PATH%). But GNUWin32 doesn't provide a bash, so we need to use win-bash: winbash.sf.net . At least it is a recent port, but accepts for example only linux style pathnames. Anyway, download win-bash.exe and copy it into GNUWin32\bin as bash.exe and sh.exe. So this should do the trick, if another gnu tool is needed get it from gnuwin32. If I run now ctest in my plplot build directory it runs the c and c++ test successfully. But the java test fails, because .... of the same problems I always failed so far. Bash handles everything like in Linux and the Gnuwin32 tools except that, but Java expects Windows like syntax .... In test_java.sh the important command line is: java -classpath ${javadir}:${PLPLOT_CLASSPATH} ..... The colon between javadir and PLPLOT_CLASSPATH is good for Linux, but for Windows obviously not (e.g. C:\ :), but if I replace the colon with a semicolon, which would be windows style, bash chokes up, since this ends a command or similar (I'm not a bash guru). So, again another failure to use bash in a Windows environemnt. Sigh. Anyway, I think we might be able to fix this, but I don't want to change this on my own. Alan, could you think of a solution here, which would work for Linux and Windows? Actually I would only need PLPLOT_CLASSPATH since it contains the full path to plplot.jar. > I am completely > unfamiliar with the windows scripting constraints, but if there is no easy > way to modify those scripts so they will also work on windows, then perhaps > we should use the equivalent of those scripts in python or perl for the > windows case? (I mentioned python first because I understand it and don't > understand perl, but if the windows developers are more familiar with perl, > that is the scripting language they should probably use.) In the long run, I think python scripts would be much better. Perl is not too much used in Windows I think. Python is very easy to install and is cross platform, so this would be my first option here (though I never did anything in python). But since I came that far with the bash scripts and it is kind of easy, and the normal plplot user shouldn't need it anyway, we should stick with the bash scripts, since this minimizes our efforts. We just need a little tweaking here and there. > > This build-tree enhancement for windows developers is great, and I look > forward to ctest eventually working for windows as a result, but it leads to > the question of whether the equivalent of "make install" is supported on > windows. Yes, "make install" works, for all "make"s I tested so far (nmake, wmake, mingw32-make, ...) > I hope it is since "make install" collects all essential data and > builds in a convenient and compact way for the user. If the equivalent of > make install is supported, then you should check whether you have to modify > all the INSTALL commands for the windows case to be consistent with the new > build-tree location of libraries or whether cmake automatically knows what > to do when LIBRARY_OUTPUT_PATH is set. Cmake knows where it put the dll and exe files, regardless where they are (if you set the LIBRARY_OUTPUT_PATH), no problems here. 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? Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Arjen M. <arj...@wl...> - 2006-11-27 08:15:51
|
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. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-11-27 16:25:33
|
On 2006-11-27 12:12+0100 Werner Smekal wrote: > Hi, > >> >> I'm unhappy about requiring python (or anything else non-standard) for >> running the tests. This adds another significant dependency to the build >> process. We're already asking users to install a fair bit. I guess this >> is particularly an issue for windows users. > > Yes, windows user need to spend quite a time to have everything setup. > That's the reason why I thought we should provide a binary package for > Windows with libraries for MinGW and Visual C++ 6.0 (which can be used > for all other Visual C++ as well, I think). Together with the headers > and data files. This is actually all you need for c/c++ development on > Windows. > > Apart from that, it may be the smartest than to write Windows batch > files or jim/tcl files. From the jim website I think it should be no > problem that jim compiles on most compilers - I'll write a cmake file > and test it on various Windows compilers. Hmm... It's interesting how my comment about a parallel windows scripting system for ctest has sparked so much interest. A consensus seems to have formed for building jim/tcl as part of PLplot and making jim scripts with the same functionality as plplot-test.sh and the various test*.sh scripts, but I have two reservations about this solution. 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. 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. 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. :-) 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 __________________________ |
From: Werner S. <sm...@ia...> - 2006-11-27 20:42:10
|
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 |
From: Alan W. I. <ir...@be...> - 2006-11-29 16:52:35
|
On 2006-11-29 12:06+0100 Arjen Markus wrote: > Argh, why didn't I think of that! You are most probably right. Well, I > will check > what is happening (or rather, what is not happening) later then. > (Debugging shell > scripts is always, well, cumbersome) Just learned a trick about that from (http://iptables-tutorial.frozentux.net/chunkyhtml/x4983.html). Temporarily replace #!/bin/bash with #!/bin/bash -x That prints out everything as the script proceeds which is extremely useful for debugging. (Probably one of those things virtually everybody knows who has worked seriously with scripts, but I was not aware of it until a few days ago.) 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 __________________________ |
From: Werner S. <sm...@ia...> - 2006-11-29 17:05:23
|
Hi Alan, thanks for the hint. It shows that it finds the file: C:\DevZone\plplot\buildnmake\test>bash -x plplot_test.sh + version=5.7.1 + dirname= + EXAMPLES_DIR=. + SRC_EXAMPLES_DIR=. + OUTPUT_DIR=. + device=psc + export EXAMPLES_DIR SRC_EXAMPLES_DIR OUTPUT_DIR device + test 0 -gt 0 + test ! -d ./c + cat plplot_test.sh: 248352: No such file or directory + exit 1 but there are some problems later on. That will make the hacking easier :) Thanks, Werner Alan W. Irwin wrote: > On 2006-11-29 12:06+0100 Arjen Markus wrote: > >> Argh, why didn't I think of that! You are most probably right. Well, I >> will check >> what is happening (or rather, what is not happening) later then. >> (Debugging shell >> scripts is always, well, cumbersome) > > Just learned a trick about that from > (http://iptables-tutorial.frozentux.net/chunkyhtml/x4983.html). > > Temporarily replace #!/bin/bash with #!/bin/bash -x > > That prints out everything as the script proceeds which is extremely useful for > debugging. > > (Probably one of those things virtually everybody knows who has worked > seriously with scripts, but I was not aware of it until a few days ago.) > > 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 > __________________________ > > ------------------------------------------------------------------------- > 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.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Arjen M. <arj...@wl...> - 2006-11-27 07:41:28
|
Werner Smekal wrote: >Hi, > >I just committed a small change to plplot which should make life for >windows developing easier (thanks for the hint, Alan): > >In CMakeLists.txt of the plplot main directory I added > >if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN) > SET(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll) >endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN) > >If we have shared libraries, Windows but not cygwin, all created >libraries go into the dll directory. If you > >set PATH=path_to_plplot_build_dir\dll;%PATH% > >and > >set PLPLOT_LIB=path_to_plplot_dir\data > >all examples run without further copying of dlls, fonts, maps, etc. Both >variables could be set in a batch file, which you run at CLI startup. >Arjen, could you please check if this also works for you? Do you also >need other stuff (exes?) to be copied or so? > > Hi Werner, I checked your changes using bare Windows (MSVC 6.0 and ordinary makefiles but that should not really matter): - It works for C and Fortran 95 - all relevant DLLs are stored in the dll subdirectory and by expanding the PATH, the examples work fine. - The directory I have to set PLPLOT_LIB to is the one in the _source_ tree - we need to install/copy the font files to a "data" subdirectory in the build/install tree - I get a failure for the Tcl examples, but I have not been able yet to trace what is causing it (did not have the time). I will look into this ASAP. - We may need to include MinGW somehow in the condition, but I am not sure how ... Anyway: this is a big step forward. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-11-27 07:48:10
|
Alan W. Irwin wrote: >This build-tree change is a nice first step toward getting ctest working on >windows. Of course, the problem still remains that the current ctest uses >the shell scripts plplot-test.sh and test*.sh, and I assume (but correct me >if I am wrong) those scripts will not work on bare windows. > 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. > I am completely >unfamiliar with the windows scripting constraints, but if there is no easy >way to modify those scripts so they will also work on windows, then perhaps >we should use the equivalent of those scripts in python or perl for the >windows case? (I mentioned python first because I understand it and don't >understand perl, but if the windows developers are more familiar with perl, >that is the scripting language they should probably use.) > > 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. >This build-tree enhancement for windows developers is great, and I look >forward to ctest eventually working for windows as a result, but it leads to >the question of whether the equivalent of "make install" is supported on >windows. I hope it is since "make install" collects all essential data and >builds in a convenient and compact way for the user. If the equivalent of >make install is supported, then you should check whether you have to modify >all the INSTALL commands for the windows case to be consistent with the new >build-tree location of libraries or whether cmake automatically knows what >to do when LIBRARY_OUTPUT_PATH is set. > > Sofar I have not used the install part yet. I must look into that too. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-11-27 08:14:51
|
Hi Arjen, > Hi Werner, > > I checked your changes using bare Windows (MSVC 6.0 and ordinary makefiles > but that should not really matter): > - It works for C and Fortran 95 - all relevant DLLs are stored in the > dll subdirectory and > by expanding the PATH, the examples work fine. > - The directory I have to set PLPLOT_LIB to is the one in the _source_ > tree - we need > to install/copy the font files to a "data" subdirectory in the > build/install tree Yes, sorry, I wrote >> set PLPLOT_LIB=path_to_plplot_dir\data and I meant path_to_plplot_dir should be the plplot source dir and not the build dir. Since the data is not changing with the build this maybe not necessary, so you just could set the PLPLOT_LIB variable to the data directory of the source dir. "make install" than copies the files anyway into the install directory correctly. > - I get a failure for the Tcl examples, but I have not been able yet to > trace what is > causing it (did not have the time). I will look into this ASAP. You said in former emails, that you need the plserver.exe or so, and this exe files are not in the path, since only the libs are copied into the dll directory. We could also set the EXE_OUTPUT_PATH or so, but than all exe files would be copied into the directory, also all examples, and this would make the dll folder a little bit crowded, not structured and ctest wouldn't work anymore I think. Because of that I did not change this, but if you think it is necessary we could try it. > - We may need to include MinGW somehow in the condition, but I am not > sure how ... Why, do you think you need MinGW, when you use Visual C++ 6.0? Is TCL/TK depending somehow on MinGW? > Anyway: this is a big step forward. Cool, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Werner S. <sm...@ia...> - 2006-11-27 08:19:57
|
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: sm...@ia... 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 |
From: Arjen M. <arj...@wl...> - 2006-11-27 08:41:43
|
Werner Smekal wrote: > > 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 am not looking forward to learning yet another such language either. And Windows Vista may be just over the horizon, it is not a common platform as yet, so we should not target it. >> 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. I will see what can be done here. The source code for Jim is very clean, so that should be no problem. Perhaps we can simply revert to DOS batch files, but that is something I need to look into. Anyway, it would be great to unify this aspect of PLplot too. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-11-27 08:37:06
|
Werner Smekal wrote: > >> - I get a failure for the Tcl examples, but I have not been able yet >> to trace what is >> causing it (did not have the time). I will look into this ASAP. > > > You said in former emails, that you need the plserver.exe or so, and > this exe files are not in the path, since only the libs are copied > into the dll directory. No, that is (I think) with the Tk device. > We could also set the EXE_OUTPUT_PATH or so, but than all exe files > would be copied into the directory, also all examples, and this would > make the dll folder a little bit crowded, not structured and ctest > wouldn't work anymore I think. Because of that I did not change this, > but if you think it is necessary we could try it. I would not go for that: it would mean all examples will be put there as well :( > >> - We may need to include MinGW somehow in the condition, but I am not >> sure how ... > > > Why, do you think you need MinGW, when you use Visual C++ 6.0? Is > TCL/TK depending somehow on MinGW? > No, Tcl/Tk is fine without MinGW. I just noticed the condition that we only set the output path on Windows, unless we are using Cygwin. I am not sure if MinGW handles the rpath option in the same way as Cygwin. If it does, then for MinGW we do not need the output path either. Anyway, that is a territory still left open. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-11-27 08:58:25
|
Hi Arjen, > No, Tcl/Tk is fine without MinGW. I just noticed the condition that we > only set > the output path on Windows, unless we are using Cygwin. I am not sure if > MinGW > handles the rpath option in the same way as Cygwin. If it does, then for > MinGW > we do not need the output path either. Ah, ok, now I get it. MinGW would be fine here, since rpaths doesn't work here either. I should explain this in more detail. There are actually two "versions" of MinGW available for Windows. One provides just the compilers and some tools (make, etc.) which you need, but nothing else (not bash), and it is meant to be used in the Windows Shell/CLI cmd.exe. Here nothing unix like (rpath, etc.) works, it behaves exactly the same as you would use Visual C++ in a Windows Shell. The second version is called msys, and here though the exactly same compiler executables are used on top of that is a port of bash and some other tools (automake, etc.) and you don't use the Windows CLI at all. The second version behaves very much like Unix or Cygwin, e.g. the filenames are /home/user/whatever and not C:\Program Files\firefox. Msys makes it easier to port Unix programs, since you can use the configure and so on. To my knowledge (e.g. from the wxWidgets mailing list) not many Windows people use Msys - most use the MinGW tools in the Windows CLI. The reason is to my opinion, apart from msys being damn slow: because of the very same reason I failed with bash just before. At some point you want to use a Windows executable which accepts only Windows filenames and voila, you are in devils kitchen. So, Arjen, you are right, we need to also take care of MinGW, but only for msys. But since CMake doesn't provide an easy way to distinguish between MinGW in CLI and Mingw in Msys (both have MINGW set to 1) it's not that easy. I recently found out, that we can check which generator is used (cmake uses "MinGW Makefiles" for the MinGW/CLI version and "MSYS Makefiles" for msys), but I didn't test this yet. > > Anyway, that is a territory still left open. Yes, you are right, some work is still to be done here. Thanks, Werner |
From: Andrew R. <and...@us...> - 2006-11-27 09:36:31
|
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 |
From: Werner S. <sm...@ia...> - 2006-11-27 10:00:07
|
Hi, > 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. Actually using only ctest would be a good idea, especially if we ever use dashboard. > > 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. Especially the test for the user is an important point on the other hand. > > 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. I also think it's no problem to write a windows batch file. The CLI is actually quite capable ( http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true ), but it's not bash ;). And we would have to maintain two versions of the test, a unix and a windows one. Using python or jim (which actually looks very interesting, Arjen) would mean to only maintain one version. I actually have no strong opinion here, using win-bash and so on is definitely the least wanted, since problematic. Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Andrew R. <and...@us...> - 2006-11-27 10:50:55
|
On Mon, Nov 27, 2006 at 10:59:56AM +0100, Werner Smekal wrote: > Hi, > > > 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. > > Actually using only ctest would be a good idea, especially if we ever > use dashboard. Maybe we should investigate this more thoroughly. > > > > 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. > > Especially the test for the user is an important point on the other hand. > > > > 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. > > I also think it's no problem to write a windows batch file. The CLI is > actually quite capable ( > http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true > ), but it's not bash ;). And we would have to maintain two versions of > the test, a unix and a windows one. Using python or jim (which actually > looks very interesting, Arjen) would mean to only maintain one version. > > I actually have no strong opinion here, using win-bash and so on is > definitely the least wanted, since problematic. I'm unhappy about requiring python (or anything else non-standard) for running the tests. This adds another significant dependency to the build process. We're already asking users to install a fair bit. I guess this is particularly an issue for windows users. Andrew |
From: Arjen M. <arj...@wl...> - 2006-11-27 11:08:20
|
Andrew Ross wrote: >I'm unhappy about requiring python (or anything else non-standard) for >running the tests. This adds another significant dependency to the build >process. We're already asking users to install a fair bit. I guess this >is particularly an issue for windows users. > > > Which is why I would like to experiment with Jim. It is small enough to be part of the PLplot distribution, it in fact already is, and it can be built as just another component of PLplot for those platforms that require it. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-11-27 11:12:55
|
Hi, > > I'm unhappy about requiring python (or anything else non-standard) for > running the tests. This adds another significant dependency to the build > process. We're already asking users to install a fair bit. I guess this > is particularly an issue for windows users. Yes, windows user need to spend quite a time to have everything setup. That's the reason why I thought we should provide a binary package for Windows with libraries for MinGW and Visual C++ 6.0 (which can be used for all other Visual C++ as well, I think). Together with the headers and data files. This is actually all you need for c/c++ development on Windows. Apart from that, it may be the smartest than to write Windows batch files or jim/tcl files. From the jim website I think it should be no problem that jim compiles on most compilers - I'll write a cmake file and test it on various Windows compilers. Regards, Werner > > 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.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
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 __________________________ |