From: Werner S. <sm...@ia...> - 2006-11-29 17:03:48
|
Hi, > 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. Ok, in that case we have only two possibilities left, either try to make the sh scripts run with win-bash/GNUWin32, or write Windows batch files. to write tcl scripts only for windows wouldn't be a good idea, since you need jim or tcl, but windows batch files will run in any case. We might first try the win-bash approach and if we have a show stopper we can go for the windows batch files. 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-29 08:19:31
|
Alan W. Irwin wrote: >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. > > > > ... >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 appreciate your conservative approach to this topic. So I tried to get win-bash to work on my PC (http://win-bash.sf.net). Installing it is a non-issue - just get the executable and put it in a convenient directory. However, when I simply tried to run plplot-test.sh, it complained that the file did not exist - despite the fact that I gave both absolute and relative paths. It may be that I do not understand how it is supposed to operate, but it seems weird that: > win-bash .\plplot-test.sh (and any variation on the name/directory I tried) should report that the file does not exist. (I am going to file a bug report/question for this, because if it works, it would be a very useful tool). Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-11-29 10:55:28
|
Hi Arjen, > I appreciate your conservative approach to this topic. So I tried to get > win-bash > to work on my PC (http://win-bash.sf.net). Installing it is a non-issue > - just get > the executable and put it in a convenient directory. However, when I simply > tried to run plplot-test.sh, it complained that the file did not exist - > despite the > fact that I gave both absolute and relative paths. > > It may be that I do not understand how it is supposed to operate, but it > seems weird that: > > win-bash .\plplot-test.sh > > (and any variation on the name/directory I tried) should report that the > file does not exist. I think win-bash finds it, but has problems during execution, since the error message is: plplot_test.sh: 248352: No such file or directory while for executing a nonexisting file reveals no_exist.sh: no_exist.sh: No such file or directory all other sh-files (test_c.sh) "work", so maybe a file called in plplot_test.sh doesn't exist?? 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.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-29 11:06:32
|
Werner Smekal wrote: > Hi Arjen, > > > I think win-bash finds it, but has problems during execution, since > the error message is: > plplot_test.sh: 248352: No such file or directory > > while for executing a nonexisting file reveals > no_exist.sh: no_exist.sh: No such file or directory > > all other sh-files (test_c.sh) "work", so maybe a file called in > plplot_test.sh doesn't exist?? 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) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-11-29 17:49:43
|
On 2006-11-29 18:02+0100 Werner Smekal wrote: > We might first try the win-bash approach and if we have a show stopper we can > go for the windows batch files. Sounds good. On the question of win-bash showstoppers, you commmented before "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." I have just had an idea about that. I suggest you put the directory where win-bash occurs last on your PATH. For those platforms with an official shell (MinGW/MSYS, Cygwin, etc.) you will always use that official shell (which both cmake and plplot-test.sh are happy with) since that shell will be higher on the PATH than win-bash. Hope this idea helps. 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 18:48:18
|
Hi Alan, > > "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." > > I have just had an idea about that. I suggest you put the directory > where win-bash occurs last on your PATH. For those platforms with an > official shell (MinGW/MSYS, Cygwin, etc.) you will always use that official > shell (which both cmake and plplot-test.sh are happy with) since that shell > will be higher on the PATH than win-bash. Not really. This is again a Msys-MinGW story. If you have "MinGW Makefiles" as a generator, cmake checks if there is any sh.exe in the path (there shouldn't be any, since we don't use Msys, which provides on). If it finds one, cmake immediately stops, since it thinks, we are running msys and not windows cli. One possibility would be changing sh in the cmake files to "bash" or "win-bash" or whatever only for Windows. But this is not a big problem, we also could use aliases or something like that. Thanks, Werner |
From: Alan W. I. <ir...@be...> - 2006-11-29 20:50:24
|
On 2006-11-29 19:48+0100 Werner Smekal wrote: Hi Werner: >> I have just had an idea about that. I suggest you put the directory >> where win-bash occurs last on your PATH. For those platforms with an >> official shell (MinGW/MSYS, Cygwin, etc.) you will always use that >> official >> shell (which both cmake and plplot-test.sh are happy with) since that >> shell >> will be higher on the PATH than win-bash. > > Not really. This is again a Msys-MinGW story. If you have "MinGW Makefiles" > as a generator, cmake checks if there is any sh.exe in the path (there > shouldn't be any, since we don't use Msys, which provides on). If it finds > one, cmake immediately stops, since it thinks, we are running msys and not > windows cli. One possibility would be changing sh in the cmake files to > "bash" or "win-bash" or whatever only for Windows. But this is not a big > problem, we also could use aliases or something like that. My impression from lurking on the cmake mailing list was that cmake carefully distinguishes between the two MinGW variants (one with a shell and one without) and had a separate generator for each that the user could specify with the -G option. If the user specifies a non-shell cmake generator, but that generator stops if it finds a shell, that is a cmake bug which should be reported since obviously people would like to try/test the non-shell version of MinGW generator even if they have a shell installed. Note, I am just reporting what I remember from CMake list traffic about MinGW, and my memory could be completely wrong about what kinds of generators are available and the user control over them. :-( 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: Arjen M. <arj...@wl...> - 2006-11-30 07:29:45
|
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.) > > > The Bourne shell uses -s if I remember correctly, but I never thought of putting these options in the magic first line. Good idea, though! Anyway, the culprit for the failure is clear: cat. It does not exist on Windows, so I will change the script to use echo instead (as that is an internal command). Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-11-30 07:38:58
|
Hi Arjen, > The Bourne shell uses -s if I remember correctly, but I never thought of > putting these options in the magic first line. Good idea, though! > > Anyway, the culprit for the failure is clear: cat. It does not exist on > Windows, > so I will change the script to use echo instead (as that is an internal > command). I think this won't be the only command you will not find, e.g. sed is later used on, and there is no windows command I know of, that has this functionality. I use the very well ported GNUWin32 tools: http://GNUWin32.sf.net It has all the GNU Tools you need: core-utils, sed, grep, whatever (except bash though :( ). Actually I was succesful in running the sh files on my Windows box with win-bash and GNUWin32 Tools without too much problems, e.g. running "ctest" in the build directory actually run all scripts (but not all correct). But does it make sense to change sh-files to use windows commands, instead of writing windows batch files? Might be the same work? Especially if you try to get around sed :). Werner > > Regards, > > Arjen > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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-30 07:50:28
|
Werner Smekal wrote: > I think this won't be the only command you will not find, e.g. sed is > later used on, and there is no windows command I know of, that has > this functionality. I use the very well ported GNUWin32 tools: > > http://GNUWin32.sf.net > > It has all the GNU Tools you need: core-utils, sed, grep, whatever > (except bash though :( ). Actually I was succesful in running the sh > files on my Windows box with win-bash and GNUWin32 Tools without too > much problems, e.g. running "ctest" in the build directory actually > run all scripts (but not all correct). > > But does it make sense to change sh-files to use windows commands, > instead of writing windows batch files? Might be the same work? > Especially if you try to get around sed :). *ugly word elided* I forgot that bit - Windows batch files together with the native tools are very limited in this respect. But perhaps that is where a Jim script can help :). We would emulate sed for the Windows platform using Jim. The advantages: - We keep the shell scripts mostly as they are (with perhaps a few parametrisations, using $cat instead of cat and $sed instead of sed) - The Jim scripts would only be necessary on Windows - No need to get all GNU tools, we can just do with win-bash. The disadvantages: - The introduction of new scripts, however limited On the other hand, if the GNU tools are easy to install and use, for the moment at least that will suffice. BUT: I do want to prevent us requiring Windows users to download and install all manner of tools before they can get started. The installation instructions for PLplot should ideally fit in 10 lines of text, each no longer than 80 characters. (I have seen reams of documentation on how to install various software packages, and I tend to get very very depressed by them! And I think I am typical enough in that respect ;)) Regards, Arjen |
From: Bryan P. <pet...@ma...> - 2006-11-30 15:11:29
|
Actually, sed is available for windows. I have used it to process the fortran plplot sources to get the single precision versions that I use in most of my work. It works quite well. It is just an executable that you drop somewhere in your path. It can be found at http://gnuwin32.sourceforge.net/packages/sed.htm Bryan Peterson bry...@by... On Thu, 30 Nov 2006, Werner Smekal wrote: > Hi Arjen, > >> The Bourne shell uses -s if I remember correctly, but I never thought of >> putting these options in the magic first line. Good idea, though! >> >> Anyway, the culprit for the failure is clear: cat. It does not exist on >> Windows, >> so I will change the script to use echo instead (as that is an internal >> command). > > I think this won't be the only command you will not find, e.g. sed is > later used on, and there is no windows command I know of, that has this > functionality. I use the very well ported GNUWin32 tools: > > http://GNUWin32.sf.net > > It has all the GNU Tools you need: core-utils, sed, grep, whatever > (except bash though :( ). Actually I was succesful in running the sh > files on my Windows box with win-bash and GNUWin32 Tools without too > much problems, e.g. running "ctest" in the build directory actually run > all scripts (but not all correct). > > But does it make sense to change sh-files to use windows commands, > instead of writing windows batch files? Might be the same work? > Especially if you try to get around sed :). > > Werner > > >> >> Regards, >> >> Arjen >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> 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 > > ------------------------------------------------------------------------- > 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 > |
From: Alan W. I. <ir...@be...> - 2006-11-30 09:40:49
|
On 2006-11-30 08:50+0100 Arjen Markus wrote: > BUT: I do want to prevent us requiring Windows users to download and install > all manner of tools before they can get started. The installation > instructions for > PLplot should ideally fit in 10 lines of text, each no longer than 80 > characters. > > (I have seen reams of documentation on how to install various software > packages, > and I tend to get very very depressed by them! And I think I am typical > enough > in that respect ;)) I take your point so we should eliminate the extra GNUWin32 tools dependency since that appears to be easy to do. Here are the issues and my suggested solutions. (1) cat. I think the best thing to do with cat is to replace it by a series of echo commands. See scripts/make_tarball.sh script where the usage message is printed out that way. "echo" is supplied by the bash shell so using it should be okay for win-bash (but please check). (2) sed We use that command in plplot-test.sh to allow cross-platform parsing for all the different unix shells. We should keep that use of sed as an alternative for just that reason, but if (say) HAVE_BASH is set (we will have to provide a bash test for our CBS to set that up), the script should use the powerful bash parsing features instead of sed. A google search came up with one bash parsing feature which appears to be exactly what we need. I illustrate this parsing feature as follows: irwin@chickadee> xxxx='hello=3941' irwin@chickadee> echo ${xxxx#*=} 3941 So this method of parsing out everything after the equals sign in a plplot-test.sh option should just work with win-bash, but please check. (There is also one other use of sed in plplot-test.sh, but it is just a backup if some other method fails so we probably do not need to deal with it.) Anyhow, it is past time for me to get some sleep, but if one of you guys does not implement the above simple changes first, I will do that tomorrow evening (European time) and that may be all we need to get ctest scripts to work on bare windows (without the extra GNUWin32 tools dependency). 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: Alan W. I. <ir...@be...> - 2006-11-30 23:46:09
|
On 2006-11-30 01:40-0800 Alan W. Irwin wrote: > [...]if one of you guys > does not implement the above simple changes first, I will do that tomorrow > evening (European time) and that may be all we need to get ctest scripts to > work on bare windows (without the extra GNUWin32 tools dependency). Done (and yes, it was really simple.) Werner and Arjen, please test the win-bash case where GNUWin32 tools are not installed to see whether there are any problems left with this approach. 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: Arjen M. <arj...@wl...> - 2006-12-01 09:16:09
|
> On 2006-11-30 01:40-0800 Alan W. Irwin wrote: > >> [...]if one of you guys >> does not implement the above simple changes first, I will do that >> tomorrow evening (European time) and that may be all we need to get >> ctest scripts to work on bare windows (without the extra GNUWin32 >> tools dependency). > > Done (and yes, it was really simple.) Werner and Arjen, please test the > win-bash case where GNUWin32 tools are not installed to see whether > there are any problems left with this approach. > Hello Alan, wonderful news: I like that approach. However, I must report now a very unfortunate problem: With the latest CVS update CMake refuses to build the examples, so I can not check your changes! Here are the relevant messages: -- Looking for pkg-config -- Looking for pkg-config - not found -- WARNING: Build of examples will not work. Everything is built, but there are no examples for me to check. I had to change the # in pkg-config.cmake to get them to work again ... No, that did not work! I have looked into the various CMake files and Makefile templates, but I can not determine why it is not working. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-12-01 15:00:15
|
On 2006-12-01 10:15+0100 Arjen Markus wrote: >> On 2006-11-30 01:40-0800 Alan W. Irwin wrote: >> >>> [...]if one of you guys >>> does not implement the above simple changes first, I will do that >>> tomorrow evening (European time) and that may be all we need to get >>> ctest scripts to work on bare windows (without the extra GNUWin32 >>> tools dependency). >> >> Done (and yes, it was really simple.) Werner and Arjen, please test the >> win-bash case where GNUWin32 tools are not installed to see whether >> there are any problems left with this approach. >> > > Hello Alan, > > wonderful news: I like that approach. > > However, I must report now a very unfortunate problem: > With the latest CVS update CMake refuses to build the examples, so > I can not check your changes! > > Here are the relevant messages: > > -- Looking for pkg-config > -- Looking for pkg-config - not found > -- WARNING: Build of examples will not work. We use pkg-config to build the examples in the _install_ tree. This has nothing to do with ctest or build-tree tests so I have changed that message to make it more clear. I suggest you look over my recent changes that were automatically sent to the plplot-cvs mailing list. To explain further, the build tree build of examples is controlled by BUILD_TEST. Did you turn that ON? Note, if a shell (win-bash in your case) cannot be found, BUILD_TEST is turned OFF internally, but with the following WARNING message: WARNING: shell not found, disabling ctest and install tree examples tests Look at cmake/modules/plplot.cmake for the logic, and the changes to test/CMakeLists.txt which completely turn off everything to do with testing if a shell was not found. You may have to set your PATH (or whatever is the windows equivalent) so that the find_program(SH_EXECUTABLE bash) works. If the name of the program is actually win-bash rather than bash in your case you should use the following logic instead: find_program(SH_EXECUTABLE bash) find_program(SH_EXECUTABLE win-bash) The first one works on Unix, and the second one may be necessary on windows where win-bash is installed, but I am not sure. Let me know how it goes. 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-12-01 22:12:29
|
Hi Alan, > find_program(SH_EXECUTABLE bash) > > works. If the name of the program is actually win-bash rather than bash in > your case you should use the following logic instead: > > find_program(SH_EXECUTABLE bash) > find_program(SH_EXECUTABLE win-bash) > > The first one works on Unix, and the second one may be necessary on windows > where win-bash is installed, but I am not sure. I made some changes, but before I cvs it, I want your comment on this: I added as you wrote the win-bash line find_program(SH_EXECUTABLE bash) find_program(SH_EXECUTABLE win-bash) if(SH_EXECUTABLE) set(HAVE_BASH ON) else(SH_EXECUTABLE) find_program(SH_EXECUTABLE sh) endif(SH_EXECUTABLE) Important here is, that SH_EXECUTABLE is either bash, or win-bash or in some cases only sh (on unix without bash), with full absolute path. Problem is now, that in some of the test scripts "sh" is used - what I did was to replace that with @SH_EXECUTABLE@ - worked ok on windows, should also work on linux, shouldn't it? Also the first line of all sh files needs to be replaced from #!/bin/sh to #!@SH_EXECUTABLE@ - this will be in most cases now bash instead of sh, but this is no problem isn't it? But on the other hand, are this scripts also used by the (deprecated) automake build system? Are these changes allowed than? in plplot-test.sh is another line at the end, which wants sed. Is it possible to replace it? If not, we can make conditional win32 execution with if test "@WIN32@" = "1"; then code for windows else code for all others fi or? We need that in any case for the Java script, since the java call is not windows compliant. But it looks, that this actually works out much better than I thought. So for Windows you just put another executable (win-bash) in the PATH. That's ok. There is actually another bash provided by djgpp, which also runs in Windows. You can find it here: http://www.delorie.com/pub/djgpp/current/v2gnu/ The zip file we need is: bsh204b.zip (bash 2.04 binary) Just in case win-bash is not good enough for our needs, we could try this bash. 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-12-02 00:43:48
|
On 2006-12-01 23:11+0100 Werner Smekal wrote: > Hi Alan, > >> find_program(SH_EXECUTABLE bash) >> >> works. If the name of the program is actually win-bash rather than bash in >> your case you should use the following logic instead: >> >> find_program(SH_EXECUTABLE bash) >> find_program(SH_EXECUTABLE win-bash) >> >> The first one works on Unix, and the second one may be necessary on windows >> where win-bash is installed, but I am not sure. > > I made some changes, but before I cvs it, I want your comment on this: I > added as you wrote the win-bash line > > find_program(SH_EXECUTABLE bash) > find_program(SH_EXECUTABLE win-bash) > if(SH_EXECUTABLE) > set(HAVE_BASH ON) > else(SH_EXECUTABLE) > find_program(SH_EXECUTABLE sh) > endif(SH_EXECUTABLE) > > Important here is, that SH_EXECUTABLE is either bash, or win-bash or in > some cases only sh (on unix without bash), with full absolute path. > Problem is now, that in some of the test scripts "sh" is used - what I > did was to replace that with @SH_EXECUTABLE@ - worked ok on windows, > should also work on linux, shouldn't it? Also the first line of all sh > files needs to be replaced from #!/bin/sh to #!@SH_EXECUTABLE@ - this > will be in most cases now bash instead of sh, but this is no problem > isn't it? Yes, everything seems fine. Go ahead and commit your proposed changes. > But on the other hand, are this scripts also used by the > (deprecated) automake build system? Are these changes allowed than? Well, your changes will stop autotools tests. I will fix this up (by defining SH_EXECUTABLE in autotools to be /bin/sh) after your commit with low priority since the number of cvs autotools users at the moment who are running tests must be pretty low. > > in plplot-test.sh is another line at the end, which wants sed. Is it > possible to replace it? Well, that sed construct is trying to find the directory name where the script resides, i.e., the directory name corresponding to $0. when bash is available you can use the '%CHARACTER*' parsing construct to remove everything from the last CHARACTER onward in the string. Here is a simple example of this parsing construct (taken from http://tldp.org/LDP/abs/html/parameter-substitution.html which is an extremely helpful reference): irwin@chickadee> xxxx=/home/user/xxx.yyy irwin@chickadee> echo ${xxxx%/*} /home/user So ${0%/*} should get the directory of $0 in the Unix/bash case, but you may need to replace the unix directory separator "/" with the windows directory separator "\" in the win-bash case. Anyhow, once you have sorted this out, then just go ahead and commit, and we will correct it on the Unix side of things if necessary. (It's not the end of the world if the test system quits working for a bit.) 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: Alan W. I. <ir...@be...> - 2006-11-26 01:10:20
|
On 2006-11-25 22:47+0100 Werner Smekal wrote: > I searched the whole plplot tree where we would set python24_d.lib, but I > couldn't find anything like that. We set PYTHON_LIBRARIES in cmake/modules/python.cmake, and I am virtually positive that is how python24_d.lib is found. If cmake did not find a python library, then it would have disabled python completely. To build the two python interfaces on windows you need to link to PYTHON_LIBRARIES. (See /bindings/python/CMakeLists.txt.) So I suspect the real question is why python24_d.lib is not accessible to the linker on bare windows even though cmake found it. Hope that background information helps, and thanks very much for your continued windows/python efforts. 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 21:43:15
|
Hi Alan, thanks for the help. Actually python was the problem. In Visual C++ you can set libraries in the code itself with #pragma directives. Python sets in its header files to link to the python24_d.lib if _DEBUG is defined. If I #undef it just before I include Python.h it compiles and works. I still have to rename _plplotcmodule.dll to _plplotc.dll and it must be in the same directory as the python script, it doesn't work if the dll is only in the PATH. So, I either have to find where we get the python24_d.lib or have to hack the cmake files to not set _DEBUG for the Visual C++ case. Thanks, Werner Alan W. Irwin wrote: > On 2006-11-25 22:47+0100 Werner Smekal wrote: > >> I searched the whole plplot tree where we would set python24_d.lib, but I >> couldn't find anything like that. > > We set PYTHON_LIBRARIES in cmake/modules/python.cmake, and I am virtually > positive that is how python24_d.lib is found. If cmake did not find a > python library, then it would have disabled python completely. To build the > two python interfaces on windows you need to link to PYTHON_LIBRARIES. (See > /bindings/python/CMakeLists.txt.) So I suspect the real question is why > python24_d.lib is not accessible to the linker on bare windows even though > cmake found it. > > Hope that background information helps, and thanks very much for your > continued windows/python efforts. > > 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 |