Re: [Plplot-devel] Your development plans for this release cycle

[Arjen M. <Arj...@de...>]

Hi Alan,



Apologies for the late answer. The further strengthening of the Cygwin and MinGW-w64/MSYS2 platforms (the latter in its dual guises) is a goal worthwhile to pursue. A similar action could be taken for bare Windows and in conjunction (with perhaps a higher priority, a more extensive testing facility, based on bash and the comprehensive tests already available) - many packages are available but Windows simply does not make it easy to automatically find them, once installed. So that will be the main goal for me.



A secondary goal, which has been on my wishlist for a long time now and with the new Fortran binding nicely into place, is a modernisation of the Tcl binding. There we still use the string-based variant, rather than the Tcl_Obj-based one, which is more efficient.



The first thing for me to do is to reorganise the Windows-specific test facility, however ad-hockish in nature it currently is. I will probably not be able to do much though before next week (attending a conference abroad).



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, January 30, 2017 3:48 AM
> To: Arjen Markus; PLplot development list
> Subject: Your development plans for this release cycle
>
> 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%20Repor
> ts>
>
> 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
> __________________________

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.