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...@beluga.phys.uvic.ca]
> 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.
------------------------------------------------------------------------------
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
