Hi Arjen: Now that 5.12.0 has been released, I am writing a series of posts to our active developers with this subject line, and you are first in line!. :-)
If you have some further development in mind for this release cycle, please let us know. In addition, I would appreciate you moving forward on the comprehensive testing front on (1) MinGW-w64/MSYS2 (2) the MinGW-w64 part of MinGW/MSYS2, and (3) MSVC. 1. MinGW-w64/MSYS2 (using the "MSYS Makefiles" or "Unix Makefiles" generator). This platform is the modern equivalent of the classic MinGW/MSYS platform (but with a far larger set of free software libraries available and likely many fewer platform bugs). You have already had partial success with this platform, and the trick here is to update that platform with all the development tools (e.g. the MingGW-w64 version of cmake and the MSYS2 version of make) and all the MingGW-w64 libraries that add power to PLplot to make this test as comprehensive as possible. There is no urgency about this, but nevertheless from my perspective (with no release distracting me) now would be and ideal time for you to go ahead with this so I can add your full-powered version of this Windows platform to our tally at <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports> and <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Reports> 2. MinGW-w64 alone (using the "MinGW Makefiles" generator). This platform is the modern equivalent of MinGW. Based on my historical experience with that platform under Wine, this should "just work" with CMake finding all the native libraries built by the MinGW-w64/MSYS2 platform that are needed by PLplot. So this platform should in theory be just as complete as MinGW-w64/MSYS2 and also Cygwin. N.B. The trick to get the testing of PLplot to "just work" on this platform is to copy the MSYS2 set of Unix tools (except for sh.exe) to a different directory and put that directory on your PATH AFTER the directory pointing to the MinGW-w64 set of applications such as the MinGW-w64 version of make. The point of this is the MinGW-w64 version of make you should be using for this exercise acts quite differently if sh.exe is on your PATH. That is, that version of make apparently does not work correctly in a CMD environment unless sh.exe is _not_ available. Therefore, the "MinGW Makefiles" generator only works with sh.exe removed from the path (as with the above trick). Thus, this build is done completely under a CMD environment with the MinGW-w64 version of make from the MinGW-w64/MSYS2 platform rather than the MSYS2 version of make from that platform, but the tests are run using bash.exe and other MSYS2 Unix applications such as cmp.exe, etc. from the MinGW-w64/MSYS2 platform. 3. MSVC (using the "NMake Makefiles" generator). I am virtually positive the approach described in 2. (which I _know_ works for the classic MinGW platform) should work fine also for this platform. (Note in my Wine days I even got jom, a parallel build version of nmake to work properly on the classic MinGW platform when using the "NMake Makefiles Jom" generator.) With this approach, the actual build is done with nmake.exe (or jom.exe) in the CMD environment but all the tests are run using bash.exe and other MSYS2 Unix applications such as cmp.exe, etc., from the MinGW-w64/MSYS2 platform. You commented in December to the effect you think the suggested approach (for 2. or 3.) would be somewhat too exotic to be of much use to users. I mostly agree unless you are a Windows user that likes Unix tools. However, I still argue that you personally going to this extra trouble to make comprehensive tests for the MinGW-w64 and MSVC platforms will be a big help to PLplot development. After all, those tests comprehensively check whether all components of native windows PLplot built (against the native windows MinGW-w64 free software libraries that give PLplot its power) and installed with CMake in a CMD environment work properly (at least under bash.exe at run time) for all our major configurations. And if you supplement such comprehensive run-time tests under bash.exe with a smaller set of run-time tests under a CMD environment like you have done recently with the windows batch file, scripts/run_examples_windows.bat, then it could be argued you have a really strong test result since anything possible under bash.exe at run time should also work fine under CMD at run time. So that combined test result will be a big benefit to users of the MinGW-w64 platform who avoid using any of the MSYS2 unix components from the full MinGW-w64/MSYS2 platform. And a similar argument can be made in the MSVC case assuming you can get comprehensive testing of what you build there with nmake in a CMD environment to work at run-time as outlined in 3. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
