Hi Alan, the picture you sketch is quite a bit more encouraging than a simple-minded "install MSYS/MinGW". I think with this we should be able to go ahead with MSYS-bash as the recommended bash version.
(Contorting the test code just to make sure that all works for a very old version of bash can be only be taken so far) Regards, Arjen On 2010-04-06 11:39, Alan W. Irwin wrote: > 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 > ------------------------------------------------------------------------------ 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
