Hi Arjen: On 2015-04-15 07:00-0000 Arjen Markus wrote:
> [...] That [quick release cycles, pushes of major changes only in the first part of the release cycle] seems a wise approach. I can not predict whether I will be able to get the Fortran bindings reorganised as we planned before that time, but given that we are working to short release cycles, that should be less of a problem. The thing is I realised that my current approach leads to much more code than is required, and especially duplication thereof. I want to explore an alternative I have in mind. Sounds intriguing. I will certainly be willing to test whatever you decide to implement. > The past period has also revealed a number of things regarding Windows (especially MinGW/MSYS) that should be made smoother and that is something I would like to explore as well. I fully agree making the PLplot experience much smoother for all the many different Windows platforms is a really important topic. But from my perspective, I think the priority of the platforms should 1. Cygwin, 2. MinGW-w64/MSYS2, 3. the MSVC family of platforms, and 4., finally MinGW/MSYS. Perhaps that is all I should say since you have a lot more Windows experience than I do, and you will be doing a lot more of such testing than I can do with Wine because of its lack of speed. However, here are my reasons why I would suggest this order of priorities for you or anyone else wanting to help out with our comprehensive testing of PLplot components on Windows platforms. 1. With Cygwin you have already demonstrated complete (except for the interactive part) comprehensive test success for a small number of PLplot components. So that gives you an excellent starting point, and because the major open-source packages that are PLplot soft dependencies are already available for the Cygwin distribution, and the minor PLplot soft dependencies are easy to build (e.g., qhull, shapelib, libLASi) there is good hope you can expand relatively rapidly from that initial success to comprehensive test success on Cygwin for most/all PLplot components. 2. Once you have achieved that complete success on Cygwin for all components of PLplot, I suggest the second priority should be MinGW-w64/MSYS2 because of its many similarities with Cygwin including a distribution of free libraries that is similar in size and extent to the Cygwin distribution of free libraries (since apparently an automatically generated reconfiguration of software package builds for Cygwin can be used to derive MinGW-w64-MSYS2 package builds). However, MinGW-w64/MSYS2 also apparently has the big advantage of classical MinGW/MSYS over Cygwin which is it relies on native Windows tools rather than the Cygwin dll. For these reasons it is rapidly becoming an extremely popular Windows platform as can be seen from the following monthly download statistics (taken from <https://sourceforge.net/projects/msys2/files/>): 2014-04 16,524 2014-05 12,047 2014-06 12,778 2014-07 14,157 2014-08 18,684 2014-09 21,588 2014-10 26,008 2014-11 29,550 2014-12 139,340 2015-01 343,260 2015-02 339,326 2015-03 493,047 This is obviously phenomenal growth over the last year with no end in sight so this is a platform we really do not want to ignore. 3. I have no way of measuring the popularity of the MSVC family of platforms, but I assume that family is quite popular because the CMake developers devote a large effort to it (consisting now of 8 different visual studio generators and counting), and you and Phil do hand-crafted tests of a limited set of PLplot components on that platform from time to time. Thus, I feel strongly it is a worthwhile goal (after complete success for Cygwin and MinGW-w64/MSYS2) to expand that current MSVC testing to running scripts/comprehensive_test.sh (e.g., run the full set of 21 different test configuration combinations available with that script) for at least a limited subset of the PLplot components. However, running that script for all components of PLplot is very likely only a distant goal on this platform since in contrast to Cygwin and MinGW-w64-MSYS2 most of the PLplot soft dependencies are not available in a MSVC distribution. Thus, the only alternative for MSVC is to build these soft dependencies yourself. One can use the epa_build approach to help keep track of exactly what build methods work, but finding out that essential information for each package in a dependency tree starting with the soft dependencies of PLplot is non-trivial. 4. MinGW/MSYS is still a very popular project from the user perspective, but I rank this platform as our last priority because of two real issues with it and a possible speculative issue with it. i. The number of free software libraries that are installable with MSYS is quite limited which makes an epa_build-like approach necessary to test more than a tiny subset of the PLplot components. ii. The inability of that platform's developers to fix a parallel build regression on that platform that was introduced several years ago now (and which apparently has never affected either Cygwin or MinGW-w64/MSYS2). This regression can be worked around by limiting yourself to no parallel builds of any kind on MinGW/MSYS, but that completely wastes the resources of multi-processor machines. I actually used parallel builds for my own recent 30-hour MinGW/MSYS/Wine tests but one of those tests failed the first time because of parallel build issues and (only by chance I assume) worked the second time. Thus, that is likely the last time I will try parallel builds on that platform, but I am not looking forward to 60-90 hour tests if I ever attempt to test that platform again on Wine. iii. To speculate further, my opinion is that an unfixed egregious regression like this is likely a symptom of not enough personnel to deal with the issue (likely caused by potential or even current MinGW/MSYS developers choosing to join the rapidly growing MinGW-w64/MSYS2 project instead of maintaining MinGW/MSYS any further). If this speculation proves to be correct, then MinGW/MSYS is, of course, in big trouble in the long run, but in the short run we should continue to test on this platform in a non-parallel way (as our lowest priority among Windows platform). 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 __________________________ ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
