On 2010-04-06 08:00+0200 Werner Smekal wrote: > Hi Alan, > >> My recent experiences with MSYS-bash under Wine have been good. It's version >> is >> >> bash.exe-3.1$ bash --version >> GNU bash, version 3.1.17(1)-release (i686-pc-msys) >> Copyright (C) 2005 Free Software Foundation, Inc. >> >> [...] >> easy sell. The advantage to us of this change is that if we switch our >> Windows testers from winbash to MSYS-bash, that will put many fewer >> constraints on any future test script changes we might want to make. > > Reason is, that you either work in MSys with MinGW or in the command > line shell of Windows (cmd.exe) with MinGW. But you can't/should not > work in both. E.g. MSys doesn't know about C:\, can't take care of \ in > filenames, etc. > > I have to admit, that I have never tested using MSys bash for ctest, but > usually most (?, assumption on my side) programmers who are using MinGW > use the command line shell or an IDE. MSys is incredible slow on Windows > (even compilation), so I wouldn't recommend it using it for daily > programming tasks - only to get an Unix based source running easily on > Windows (using autoconf).
Both of these points are understood, and also apply to win-bash. Our guiding principal should be that our Windows users should not be forced to use any version of bash for anything other than PLplot tests if they prefer to avoid using bash in their daily development. > > In addition cmake doesn't want to have MSys in the path, when you > actually want the "MinGW Generator". I remember that cmake complained if > there was an sh.exe in the path (MSys provides both bash.exe and > sh.exe). So if you want to use the MinGW/CLI combination MSys should not > be in the path (or at least you need to rename sh.exe). There is no doubt that the "MinGW Makefiles" generator specifically searches for sh on the path and craps out if it finds it there. Therefore, I agree we we should advise our PLplot testers on the Windows platform that they rename sh.exe if they want to use the "MinGW Makefiles" generator. The release notes for MSYS-bash say it has only the following Runtime requirements: msysCORE-1.0.11-bin.tar.gz (e.g. stock MSYS 1.0.11 installation) and termcap-0.20050421_1-1-msys-1.0.11-bin. msysCORE has no runtime requirements and neither does termcap N.B. there is no MinGW dependency for any of these packages. Therefore, these three packages give you complete bash functionality. I double-checked that conclusion by unpacking the above three files in a special location with the associated bin directory the only thing I added to my PATH. bash worked fine under those conditions for Wine, and I am sure it will do the same for Windows. Here is the combined bin subdirectory for that special location. w...@raven> ls /home/wine/mingw/MSYS/bash_location/bin bash.exe* cls* cmd* lnkcnv* msys-1.0.dll* msysmnt.exe* sh.exe* umount* bashbug* clsb* ftp* mount* msysinfo* ps.exe* start* which* Is there any app name there that bothers you except for the necessity to rename sh.exe if you are using the "MinGW Makefiles" generator? I also suggest you try the above experiment (download and unpack those three files in a special location and rename sh.exe) for your "MinGW Makefiles" PLplot tests to make sure all is well for those conditions on Windows. I just double-checked our build system, and it appears to me to offer maximum flexiblity on all shell issues. If the user specifies -DSH_EXECUTABLE:FILEPATH=whatever (say a renamed sh.exe), then it will take that full path name and use it for tests. If they don't, it first looks for bash, then win-bash, then, sh using the PATH. However, if there is anything about that that does not work as I have described, let me know, and I will fix it. Assuming you are happy with the results of your PLPlot tests using MSYS-bash with the "MinGW Makefiles" generator in the way I have outlined above, then I think we can go ahead and recommend MSYS-bash over winbash to our Windows testers. Note in answer to Arjen's further remarks: the strong motivation for this recommendation is winbash is seriously lacking in functionality. Werner and I kept running into those bash 1 (or perhaps win-bash) limitations again and again when debugging the ctest scripts years ago. At one point I thought we would have to give up ever testing anything with win-bash, but we finally figured out workarounds (some rather clumsy) for all win-bash issues. However, now there is a good modern bash 3 alternative available on Windows I definitely want to recommend it to our Windows testers so we don't have to be so careful of further changes to our test system. Let's face it, I am the chief instigator of such test system changes, and my principal development platform is Linux with bash 3 so it is good from the perspective of reducing bugs in our test system if the Windows testers also use bash 3. Also note, my concerns about win-bash are the principal reason I have asked you, Werner, and Hazen in the past to actually try the test_noninteractive and test_interactive targets for your Windows platforms. So when you do report back with those results, please indicate whether you are using win-bash or MSYS-bash. Of course, even if it turns out you do get good test_noninteractive and test_interactive results today a minor change I might make tomorrow for the test system that works fine for bash 3 might suddenly kill your good results on windows for win-bash. So I would strongly recommend you and all other Windows testers move to MSYS-bash as soon as possible to avoid that potential issue cause by the severe version mismatch between win-bash and modern bash. As you pointed out win-bash currently does have the one minor advantage of having to download only one package rather than three, but as my above experiment showed you can unpack those three required packages for MSYS-bash in arbitrary locations so long as you adjust your PATH accordingly. Also, MSYS devels are making noises about implementing a proper installer with package dependencies so this three versus one win-bash advantage should disappear in the future. 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
