Hi Alan, I have added my responses and findings below.
Regards, Arjen -----Original Message----- From: Alan W. Irwin <alan.w.irwin1...@gmail.com> Sent: 17 May 2019 23:21 To: Arjen Markus <arjen.mar...@deltares.nl> Cc: 'Phil Rosenberg' <p.d.rosenb...@gmail.com>; PLplot development list <Plplot-devel@lists.sourceforge.net> Subject: RE: Testing of the next PLplot release Hi Arjen: See my review of your changes below. Note depending on how quickly you can respond to the three minor issues that are left, we might have a release by early next week so I am sharing this post with the PLplot development list so other developers will also be aware that release is coming soon. By the way, for all developers here I am declaring a push freeze on code or build-system changes unless it is a specific response to a bug that we discover in the next few days. Note, that freeze still allows you to update our DocBook-generated documentation. On 2019-05-17 07:31-0000 Arjen Markus wrote: > Hi Alan, Phil, > > I made some progress - see the attached tarball. >> -----Original Message----- >> From: Alan W. Irwin <alan.w.irwin1...@gmail.com> >> Sent: 16 May 2019 12:20 >> To: Arjen Markus <arjen.mar...@deltares.nl> >> Cc: 'Phil Rosenberg' <p.d.rosenb...@gmail.com> >> Subject: RE: Testing of the next PLplot release >> >> That leaves just the following issues: >> >> * Specify -DENABLE_java=OFF to avoid non-MSY2 java being found (which in >> turn causes run-time errors). DONE. >> >> * Find MSYS2 perl rather than the Cygwin version. (The CMAKE_PREFIX_PATH >> trick may also have >> solved this issue.) SOLVED. >> * Install git (from the "mingw" repository for MinGW-w64/MSYS2). LIKELY SOLVED. The git you are using (from CMakeCache.txt) is GITCOMMAND:FILEPATH=C:/msys64/usr/bin/git.exe which is from the msys repo rather than the mingw repo. However, that git clearly works (as you can see from the first few lines of comprehensive_test.sh.out) so I think it is OK. >>AM: If you ask for "git" via "pacman -Ss git", youget a long list of packages >>that are maintained via git and therefore have "git" in their name. The only >>package that I could find which was about git itself, was "msys/git". And >>indeed, that works. >> * Specify -DENABLE_ada=OFF (for now). DONE. That leaves the following issues: >> * Use "MSYS Makefiles" to work around a wxwidgets cmake find bug for the >> "Unix Makefiles" case. NOT TRIED YET. >>AM: Not yet indeed, I seem not to have installed wxwidgets yet 😉. >> * Fix our build system to find the ".exe" version of lua. > [out of order] But lua is still presenting the problem we have seen last year > (I updated it, but to no avail): > One possible workaround for this is > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fmsys2%2FMINGW-packages%2Fissues%2F949&data=02%7C01%7C%7C9 > e4efd85aac14134bb2508d6db0d7ffa%7C15f3fe0ed7124981bc7cfe949af215bb%7C0 > %7C0%7C636937248363105436&sdata=G%2FK%2BBoN9YABlwFrgM6fRybkGikd9UM > So6M5a2YZAHHk%3D&reserved=0, but I do not know how well this will > work (I probably need to move the lua.exe executable to a different > location or rename it or some such trick) That's an ugly workaround, and it looks even uglier if you follow the link to further discussion. So I don't think we should even attempt to use it, and instead until this upstream general Windows issue for lua is correctly solved, and that fix becomes part of MSYS2, we should simply specify -DENABLE_lua=OFF. (And similarly for the Cygwin case if you run into the same issue there.) >>AM: That saves a lot of messing about 😉. I was not particularly fond of this >>workaround, as there might be considerable confusion between a script file >>lua and an executable lua.exe - on Windows the file extension does play a >>role in how things are started and I am not sure how MinGW-w64/MSYS2 handles >>that. * Python currently disabled. I assume you did that because of some pyqt5 issue. Instead, I suggest you use -DENABLE_pyqt5=OFF to allow ordinary python testing. >>AM: I turned it off because I had seen a compile error with SWIG. When I >>tried it yesterday in the straightforward build, all was well and I have Qt >>drivers, including qtwidget. So I intend to allow Python again for the >>comprehensive testing. In sum, use the "MSYS Makefiles" generator, disable lua, and be more specific about what python component you disable, and you will likely (since all this has worked before) be completely done with testing this platform for the release. By the way. With regard to that release I consider that MinGW-w64/MSYS2 is our primary Windows platform because it gives access to almost all the same PLplot-relevant free software as Cygwin, but with the very large advantage that that software is in Windows native form (i.e., no dependence on a special DLL). Furthermore, I am at a reasonable stopping point on my current PLplot development topics. Therefore, I don't plan to push those topics until after the release of 5.15.0, and I currently plan to make that release just a few days after you finalize your MinGW-w64/MSYS2 testing. This means that we will release without finalizing testing of our secondary Windows platforms (Cygwin and MSVC), but I am OK with that especially because you have an opportunity to finish off that secondary platform testing just after the release. Is that plan OK with you are do you prefer we wait to release until you have finalized testing on those secondary platforms as well? Assuming you are OK with that plan and the above three changes work for the MSYS2 case, then there is a reasonable possibility the release will be made early next week! >>AM: Just an aside: while the programs you get with MinGW-w64/MSYS2 do not >>depend on the installation of MinGWw-w64/MSYS2 and can there in principle be >>run outside the mingw64 shell, there are dependencies on various run-time >>libraries: the C examples depend on libwinpthread-1.dll, libshp-2.dll, >>libfreetype-6.dll, libqhull.dll and possibly others (I just listed the ones >>mentioned in message boxes I got when trying to run a sample program). For >>the Fortran examples I got a dependency on libgfortran-4.dll, >>libfreetype-6.dll and libshp-2.dll. So deployment is not entirely as simple >>as all that. 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. _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
