commit 9e618c0b187ffe2a274a93b55287b46b9f43ffa7 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Dec 11 17:56:32 2018 -0800 Prep for 5.14.0: Update instructions followed by the release manager for this release M README.Release_Manager_Cookbook commit 8a75fe2bfec38935e83a9f096e5179ff9cd0c96f Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Dec 11 17:28:30 2018 -0800 Prep for 5.14.0: Update the release tarball generating script These changes were to change to the JOBS paradigm used for other scripts to deal with parallel make processing, and changing the way the make verbosity level is controlled (using VERBOSE=1 make option rather than the -DCMAKE_VERBOSE_MAKEFILE=ON cmake option). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Testing) by running the script and testing its results as documented in README.Release_Manager_Cookbook. M scripts/make_tarball.sh commit eb440dda1de4ae74919d3778dadca383445c302d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Dec 11 14:58:53 2018 -0800 Prep for 5.14.0: RELEASE_DATE=2018-12-12 and adjust for new version of plplot-doc-check This update of RELEASE_DATE is consistent with the expected UTC date of the 5.14.0 release and affects only the generated website documentation. The new version (thanks to Hal Wang for this) of castxml-ready plplot-doc-check code was required because the old version of that code used the gccxml app which is not available for Debian Testing because it has been completely superseded by castxml. So this change is part of the overall project to make PLplot consistent with the modern versions of free software. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Testing) by building a local version of the website using time (echo irwin$'\n'irwin$'\n'merlin$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh) and checking that the generated documentation had the correct release date. In addition, PLplot was configured with the cmake option -DADD_SPECIAL_CONSISTENCY_CHECKING=ON which configures the check_api_xml_consistency target. Building that target runs the castxml-ready plplot-doc-check appropriately. Building that target with an artificially introduced local api.xml inconsistency quickly identified that inconsistency. So this golang app seems to be a good one for finding such inconsistencies. Finally, building that target without an introduced inconsistency showed api.xml is consistent with plplot.h which is a good thing to establish since it means our DocBook-generated documentation concerning our API is consistent with our actual API! M doc/docbook/src/CMakeLists.txt commit c1871353a12195f7b0df10d5875623f27375dc6b Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Dec 11 11:20:00 2018 -0800 Prep for 5.14.0: Fix release critical bug introduced by commit plplot-5.13.0-47-g124a0c3a2 This bug was initially exposed by example 3 where all graphical elements were lost in the results leaving only text that was plotted regardless of device. But later I discovered any use of a non-zero -ori option for any of the rest of the examples also triggered this same loss of all graphical elements in plotted results regardless of device. I used make -j16 x01c ; make -j16 cairo examples/c/x01c -dev xcairo -ori 0.001 as a test case and discovered via git bisect that commit plplot-5.13.0-47-g124a0c3a2 was the first to show the bad behaviour. One component of that commit was bogus since it changed from calculating plsc->diclpxmi, plsc->diclpxma, plsc->diclpymi, and plsc->diclyma to (incorrectly) calculating those same values for the incorrect plsc elements, plsc->clpxmi, plsc->clpxma, plsc->clpymi, and plsc->clyma. Assuming the original code was correct, for this commit, I have reversed that part of commit plplot-5.13.0-47-g124a0c3a2 and discovered that solves the above "-ori 0.001" issue (i.e., all graphical elements were restored) and also solves the same issue with examples/c/x03c -dev xcairo Furthermore, commit plplot-5.13.0-47-g124a0c3a2 fixed a different rendering issue (missing graphical elements) in examples/c/x33c -dev wxwidgets that did not occur for any other device. But it turns out the present commit preserves the good rendering for the above example as well as for -dev xwin, -dev xcairo, and -dev qtwidget. And I also tried examples/c/x01c -locate -dev wxwidgets -ori 0.1 and examples/c/x33c -dev wxwidgets -ori 0.1 with perfect interaction for example 1, and perfect resizing and rendering for both examples. So I think I have found the fix for this bug with no deep understanding of why this fix works except that not updating plsc->diclpxmi, plsc->diclpxma, plsc->diclpymi, and plsc->diclyma exactly like before commit plplot-5.13.0-47-g124a0c3a2 inside calc_didev screws up all rendering when that routine is called (e.g., by the chain of calls plsdiori => pldi_ini => calc_diori => calc_didev). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Testing) by doing the rendering tests described above for example 1, example 3 and example 33 and by running COMPREHENSIVE_TEST_PREFIX="/home/software/plplot/HEAD/comprehensive_test_disposeable blank" time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.13.1/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "$COMPREHENSIVE_TEST_PREFIX" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DPLD_extqt=OFF" --build_command "make -j16" --ctest_command "ctest -j16" --do_submit_dashboard yes) where -DUSE_INCRTCL_VERSION_4=ON is needed on this Debian Testing platform to find Tcl/Tk, and -DPLD_extqt=OFF is needed to skip comprehensive tests of qt_example and pyqt5 which sometimes segfault in ways that will be investigated post-release. The above command was followed by the evaluation procedure of comprehensive test results documented in doc/wiki_source/Testing_PLplot. That evaluation showed there were no configure, build, or obvious run-time errors (i.e., no non-zero return codes for any of the steps in this comprehensive test), and the difference test results were perfect. I also regenerated the local version of the website using time (echo irwin$'\n'irwin$'\n'merlin$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh) and that local website passed all tests documented in README.Release_Manager_Cookbook including that the example 3 screenshot had its graphical elements rendered correctly (where the lack of those was the first symptom to set off this bug hunt). M src/plcore.c commit b5108131ff70561d843296945493595f116f8752 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 10 23:51:30 2018 -0800 Prep for 5.14.0: update handling of parallel build option in scripts used for website update Previous to this change, we used in these scripts an undocumented PARALLEL_BUILD_OPTION=-j10 or for htdocs-gen_plot-examples.sh we used the incorrect (so I have no idea how it worked before without the hyphen) PARALLEL_BUILD_OPTION=j10 and later in these two scripts we used the style make $PARALLEL_BUILD_OPTION <targetname> to handle parallel builds. But now we use a different style in these two scripts which is setting a well-documented value of JOBS=16 and later in these two scripts we used the style make -j$JOBS <targetname> Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Testing) by testing local website generation (which uses these two scripts) as documented in README.Release_Manager_Cookbook. N.B. That local website testing found a release-critical bug in anything to do with reorientation of plots in the PLplot core library which was exposed by example 3 losing all graphical elements so only text was left in the plot. That bug will be addressed next. M scripts/generate_website.sh M scripts/htdocs-gen_plot-examples.sh commit c8f41d3197941be632df054674e970e7b17e9cdd Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 10 13:47:46 2018 -0800 Prep for 5.14.0 release: Update swig documentation to be consistent with DocBook documentation I implemented this change by configuring PLplot with -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the check_swig_documentation target. I checked differences between the build-tree version of swig_documentation.i that is generated by that target and the older source-tree version. That diff looked good so I copied the build-tree version on top of the source-tree version. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Testing) by configuring PLplot with -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the check_swig_documentation target without issues (after the above copy). I used "git diff" to evaluate the changes to the source-tree version of swig_documentation.i, and I also ran the python and octave documentation tests decribed in doc/docbook/README.developers to confirm the changes seemed appropriate. N.B. The Python test showed a (likely long-standing) indentation issue in the Python documentation that is associated with the <parameter> DocBook tag. This issue will need further investigation after the 5.14.0 release. M bindings/swig-support/swig_documentation.i commit 2ac040345edbd84ab004359cbc4cb0397c75f2af Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 10 13:02:17 2018 -0800 In preparation for the 5.14.0 release, make check_plplot_h.inc target build without deprecation warnings This commit is also part of the overall upgrade of PLplot to be consistent with the modern free software stack (Debian Testing in this case). In this case to stop the deprecation warnings by modern OCaml software we adjusted the OCaml logic in touchup.ml to replace the deprecated String.lowercase with String.lowercase_ascii. We made sure that this is the only place where we used this deprecated function using software@merlin> find . -type f |grep -v .git |xargs grep String.lowercase Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Testing) by building the check_plplot_h.inc target without any warnings or errors. M bindings/ocaml/touchup.ml commit ee1583dece821e68a46be0b4d9114c9a376d2b82 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 10 12:55:04 2018 -0800 In preparation for the 5.14.0 release, update the instructions for testing our DocBook documentation This commit is also part of the overall upgrade of PLplot to be consistent with the modern free software stack (Debian Testing in this case). M doc/docbook/README.developers commit c89b873fd89f87a8648669f5799321750a63690d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Dec 9 17:08:22 2018 -0800 Tweak wording: two option ==> two options M doc/docbook/src/api.xml commit 8c92f45af92112d70ec7063f6e2abf61d86e4d3d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Dec 9 14:27:32 2018 -0800 Update from doxygen 1.8.8 to 1.8.13 in preparation for the release of 5.14.0 This commit is also part of the overall upgrade of our free software dependencies to Debian Testing (currently the same as Debian Buster) which is a rolling release whose free software versions are typically close to the latest upstream releases. (For example, <http://www.doxygen.nl/download.html> states the latest doxygen release right now is 1.8.14 so doxygen 1.8.13 that is packaged by Debian Testing is behind that upstream version but not by very much.) To upgrade our doxygen configuration to 1.8.13, I followed the directions in (the updated) doc/README.doxygen and executed doxygen -u Doxyfile.in I also updated the testing directions in doc/README.doxygen. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Testing) by inspecting the Doxyfile.in change generated above with "git diff" and following the additional test directions in the updated doc/README.doxygen file. M doc/Doxyfile.in M doc/README.doxygen commit 5cac57603d7137d16a2a76240be1c075ea940726 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Dec 9 01:26:11 2018 -0800 Update version information in preparation for the 5.14.0 release In particular with regard to library version numbers I looked carefully at directory-selected git log and git diff results for this release cycle, e.g., git log --name-status plplot-${old_plplot_version}..master bindings/fortran git diff --ignore-all-space plplot-${old_plplot_version}..master bindings/fortran to help decide whether one of our libraries was unchanged, had bug fixes with no API changes, had API additions, or had backwards-incompatible changes in the API, and then updated the library versions according to the [semantic versioning rules](https://semver.org/). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by using "git diff" to check for typographical errors in this change and also by running COMPREHENSIVE_TEST_PREFIX="/home/software/plplot/HEAD/comprehensive_test_disposeable blank" time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.13.1/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "$COMPREHENSIVE_TEST_PREFIX" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DPLD_extqt=OFF" --build_command "make -j16" --ctest_command "ctest -j16" --do_submit_dashboard yes --do_test_interactive no) followed by the evaluation procedure documented in doc/wiki_source/Testing_PLplot That evaluation showed there were no configure, build, or obvious run-time errors (i.e., non-zero return codes for any of the steps in this comprehensive test), and the difference test results were perfect. M cmake/modules/plplot_version.cmake M www/examples.php commit 472f35dc84a0cabc666889ef7b56250fd52231b8 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Dec 8 21:20:59 2018 -0800 Finalize the release notes for release 5.14.0 These notes were finalized based on a preliminary version of our ChangeLog for this release. The above finalized release notes are stored in README.release. I have also updated our cumulated release notes as follows: cat README.release README.cumulated_release > README.cumulated_release_new mv README.cumulated_release_new README.cumulated_release M README.cumulated_release M README.release commit 6e7b51cae6609bb22a94074eb720b1b16e960970 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Thu Dec 6 01:04:49 2018 -0800 Interim update of README.release as part of the on-going release process for 5.14.0 In preparation for the 5.14.0 release I added a number of sections to this document, and spell-checked everything. However, there are likely four more sections to add corresponding to important changes made during this release cycle before this document is ready for the release of 5.14.0. M README.release commit 39a15ae66c1429e9358bba3de9b5c5be5427891d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 3 15:01:05 2018 -0800 Add summaries of Alan's comprehensive tests for Debian Buster to our wiki Testing_Reports page Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by following the directions in README.developers to propagate all the markdown format file changes to our SF wiki and test them there. M doc/wiki_source/Testing_Reports commit 920d3983bfaa1fd7157f5f9574305171ee30db86 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Dec 2 13:37:33 2018 -0800 Fix some remaining wiki_source issues The command software@merlin> find . -name "*.png" ./doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_labels.png ./doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_bare.png ./doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Non_antialized.png ./doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Antialized.png shows that the recent wiki_source commits introduce *.png files for the first time into our git repository. This introduced two issues that were fixed in this commit. * I had to change .gitattributes to be consistent with the binary nature of those files. With the updated .gitattributes I got the following results doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Antialized.png: text: unset doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Non_antialized.png: text: unset doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_bare.png: text: unset doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_labels.png: text: unset Previous to that change the results were "auto" instead, and I was therefore concerned that those binary files had been corrupted when they were committed since the documentation of "auto" says that means git will change line endings (and therefore corrupt these binary files). However, no such corruption occurred (see test below) so I was probably saved (before the .gitattributes change) by Linux native line endings = internal git repo line endings. * I had to change scripts/remove_trailing_whitespace.sh to ignore *.png files. This commit also solves three additional issues in doc/wiki_source * I updated README.wiki to refer to the definitive directions in README.developers for propagating markdown format changes in doc/wiki_source to our SF wiki. * The updated scripts/remove_trailing_whitespace.sh indicated there were trailing white space issues in some of the markdown format files. Therefore, I instructed the script to remove the trailing white space in all of those. * I also discovered that the last few lines in some markdown format files were inconsistent with the others, e.g., no trailing 'nl' or two of those. This commit removes all those inconsistencies. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by downloading the *.png files again from the SF wiki and showing there were no differences compared to those same files in our git working directory, i.e., no corruption in the latter. I also followed the directions in README.developers to upload all the markdown format file changes to SF. M .gitattributes M doc/wiki_source/Building_PLplot M doc/wiki_source/Configure_PLplot_for_cygwin M doc/wiki_source/Configure_PLplot_for_msys2 M doc/wiki_source/Configure_PLplot_for_the_Visual_Studio_IDE M doc/wiki_source/Home M doc/wiki_source/Mac_OSX_Status M doc/wiki_source/MinGW-w64-MSYS2 M doc/wiki_source/Overview_of_the_status_on_Windows M doc/wiki_source/README.wiki M doc/wiki_source/Testing_PLplot M scripts/remove_trailing_whitespace.sh commit 46fb96f5f69ba594867356df652960bc6155b3e2 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Dec 1 22:35:37 2018 -0800 Build system bug fix: drop install of recently removed README.testing (A much newer version of this file is now named doc/wiki_source/Testing_Plplot, and along with the other files in that directory is not installed but instead used as the source of our SF wiki following the directions in README.developers.) Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the install target without errors. M CMakeLists.txt commit 0d50e2a2aeb17b5408f55bae701a702f636b0c1a Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Dec 1 18:31:10 2018 -0800 Add summaries of Arjen's comprehensive tests for Cygwin and MinGW-w64/MSYS2 to our wiki Testing_Reports page Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by cutting and pasting the change to the SF edit GUI for our Testing_Reports wiki page; saving the results there; and testing them by making sure these two table entries were rendered correctly, looking at exact differences with the previous version using the SF history GUI for Home, etc. M doc/wiki_source/Testing_Reports commit 4537147b35769bc749b8acabf2983b2185f87762 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Nov 30 13:50:49 2018 -0800 Update our directions for developers Add a new section on how to update our wiki pages. Also remove a redundant paragraph and tweak the writing. M README.developers commit 38f41b6bf5e04977ba66a77d5a934954a1c96908 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Nov 30 11:32:46 2018 -0800 Add references to Testing_PLplot and Testing_Reports to our wiki Home page Thanks, Arjen, for this good suggestion. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by cutting and pasting the change to the SF edit GUI for our Home wiki page, saving the results there, and testing them by making sure the new links from our home page were working, looking at exact differences with previous version using the SF history GUI for Home, etc. M doc/wiki_source/Home commit fbf51065de293fb7c888fa3737864c64cf67fc0d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Nov 27 18:56:00 2018 -0800 Tweak MinGW-w64-MSYS2 wiki page These tweaks consisted of spelling changes suggested by the ispell-buffer emacs command and updating the Test_Reports wiki item (the only wiki URL reference to that new wiki page), MYS2 wiki, and OpenWalnut wiki URL references. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by cutting and pasting the revised MinGW-w64-MSYS2 file to the appropriate edit session of the corresponding wiki page at SF, and looking at the wiki results and history diff results generated from that edit session for any issues caused by these tweaks. M doc/wiki_source/MinGW-w64-MSYS2 commit f7bedc70ad0cab21d36208fa434e540576898ccf Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Nov 26 22:47:18 2018 -0800 Extensive further tweaking of the recently rewritten Testing_PLplot wiki page Fixed misspellings revealed by the emacs ispell-buffer command. Reviewed all URL's (which yielded tweaks for the CDash and our CDash server references which were in a wrong form). To avoid rendering issues caused by markdown sensitivity to "*", "<", and ">" had to escape those characters as "\*", "<", and ">" when in ordinary text. I also removed many "`" escapes that I previously used in text since those created an unwanted different rendering (dark background) of what was escaped that way. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by cutting and pasting the revised Testing_PLplot file to the appropriate edit session of the corresponding wiki page at SF, and looking at the wiki results generated from that edit session for any URL or rendering issues. M doc/wiki_source/Testing_PLplot commit ee50dba3489bf15aa9c2626c22680061f16214f0 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Nov 26 20:58:35 2018 -0800 Complete rewrite of our Testing_PLplot wiki page This long-overdue rewrite included separating off the Testing reports into their own wiki page, Testing_Reports. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by cutting and pasting the (greatly) revised Testing_PLplot file and the added Testing_Reports file to appropriate edit sessions of our wiki pages at SF, and looking at the wiki results generated from those edit sessions for any obvious rendering issues caused, e.g., by "*" (rather than "\*") or "_$" (rather than "\_$") in text where the former form apparently has some markdown significance that needs to be escaped to get properly rendered results. M doc/wiki_source/Testing_PLplot A doc/wiki_source/Testing_Reports commit 501ad3dcc22991d39fd92a49e63e6c0dcfc294fd Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Nov 24 12:57:40 2018 -0800 Move definitive source of the markdown version of our wiki pages from our SF wiki editing sessions to git control This change provides automatic backup and (git) version control of our wiki markdown source files, and it allows our developers to use the editor of their choice to edit these files. This change was implemented by inserting the following boilerplate header -----------------8<------------------- <!--- N.B. The definitive Markdown source of this file is located in the doc/wiki_source subdirectory of the PLplot source tree. So only use the ctrl-v and delete capabilities of the GUI file editor at SourceForge to make changes to the SourceForge version of this file, where ctrl-v is used to complete a cut and paste from the definitive version of this file in the PLplot source tree that is being edited with your favorite file editor, and delete used to remove extraneous unmodified text whose changed form has been copied with the cut and paste. --> -----------------8<------------------- at the start of each of the SF markdown sources of our wiki pages (accessible by editing each of our wiki pages at SourceForge) then using that SF editor to select all text and use the legacy ctrl-c cut command for that edit session to start a cut and paste to the equivalent file in the doc/wiki_source subdirectory of our source tree. Note that README.testing was an older version of Testing_PLplot created in the same way. So by copying the modern version of that file to doc/wiki_source/Testing_PLplot by the above procedure and by deleting README.testing we have effectively moved README.testing to doc/wiki_source/Testing_PLplot and updated it to the latest SF version. D README.testing A doc/wiki_source/Additional_notes_for_ifort_users A doc/wiki_source/Apply_a_patch A doc/wiki_source/Aquaterm A doc/wiki_source/Building_PLplot A doc/wiki_source/Building_PLplot_with_a_cross-compiler A doc/wiki_source/CMake_options_for_PLplot A doc/wiki_source/Cairo_pango A doc/wiki_source/Configuration_of_wxWidgets_driver A doc/wiki_source/Configure_PLplot_for_Borland_CXX_5.5_(free_command_line_tools) A doc/wiki_source/Configure_PLplot_for_Borland_Turbo_C++_Explorer_Edition_(free_IDE_and_compiler) A doc/wiki_source/Configure_PLplot_for_MinGW_CLI A doc/wiki_source/Configure_PLplot_for_Visual_CXX_CLI A doc/wiki_source/Configure_PLplot_for_cygwin A doc/wiki_source/Configure_PLplot_for_msys2 A doc/wiki_source/Configure_PLplot_for_the_Visual_Studio_IDE A doc/wiki_source/Debugging_code A doc/wiki_source/Documenting_the_undocumented A doc/wiki_source/Freetype A doc/wiki_source/Frequently_Asked_Questions A doc/wiki_source/General_CMake_documentation_links A doc/wiki_source/Git_miscellanea A doc/wiki_source/Home A doc/wiki_source/Install_3rd_party_libraries A doc/wiki_source/Install_Lua A doc/wiki_source/Install_MinGW_MSYS A doc/wiki_source/Install_Octave A doc/wiki_source/Install_Python A doc/wiki_source/Install_SWIG A doc/wiki_source/Install_Tcl A doc/wiki_source/Libgd A doc/wiki_source/Linux A doc/wiki_source/List_of_Debian_Ubuntu_packages A doc/wiki_source/Lua A doc/wiki_source/Mac_OSX A doc/wiki_source/Mac_OSX_Status A doc/wiki_source/MinGW-w64-MSYS2 A doc/wiki_source/OCaml_tutorial A doc/wiki_source/Overview_of_the_status_on_Windows A doc/wiki_source/Qhull A doc/wiki_source/Qt A doc/wiki_source/README.wiki A doc/wiki_source/Setup_Visual_Studio_Express A doc/wiki_source/Setup_cygwin A doc/wiki_source/Setup_mingw A doc/wiki_source/Setup_visualc A doc/wiki_source/Setup_watcom A doc/wiki_source/Specifics_for_various_platforms A doc/wiki_source/Submit_a_patch A doc/wiki_source/Swig A doc/wiki_source/Testing_PLplot A doc/wiki_source/Third-party_libraries A doc/wiki_source/Todo_List A doc/wiki_source/Using_PLplot A doc/wiki_source/WxWidgets A doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Antialized.png A doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Non_antialized.png A doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_bare.png A doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_labels.png commit 48a56ee63d25d24eeb44f392025953a6e9cc6b3f Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Oct 19 13:45:01 2018 -0700 Fix octave test script and example familied file bugs exposed by -DPLPLOT_TEST_DEVICE=svg and -DPLPLOT_TEST_DEVICE=svgcairo The symptom of these bugs was that octave examples 14a and 31 were missing from the PLplot test device diff report for both -DPLPLOT_TEST_DEVICE=svg (the default) and -DPLPLOT_TEST_DEVICE=svgcairo. The "14a" fix was to use the correct file2 name in the test script for example 14, and to use "plSetOpt( "fflen", "2" );" in the 14th example to follow what is done for the corresponding C example. The "31" fix was to change the 31st example to drop "Test setting / getting familying parameters across plinit " and "Test setting / getting page parameters across plinit" tests which had long since been dropped from the standard 31st example for all other languages. (That first test interfered with familying so that the plot file output by octave example 31 was misnamed). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the test_diff_device target for either -DPLPLOT_TEST_DEVICE=svg (the default) or -DPLPLOT_TEST_DEVICE=svgcairo. The difference report results showed the warnings about missing 14a and 31 for octave were removed. As a result, the svg difference report results are now perfect, and the svgcairo difference report results are now reduced to java Missing examples : Differing graphical output : 24 Missing stdout : Differing stdout : octave Missing examples : Differing graphical output : 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 14a 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 33 Missing stdout : Differing stdout : python Missing examples : Differing graphical output : 09 24 Missing stdout : Differing stdout : tcl Missing examples : Differing graphical output : 03 14a 24 Missing stdout : Differing stdout : Most of the octave graphical differences for svgcairo are due to trivial renaming of surface id's, e.g., software@merlin> diff examples/test_examples_output_dir/x00[co]01.svgcairo 109c109 < <g id="surface1"> --- > <g id="surface66"> I attribute these octave id issues to the octave examples being run from one octave session rather than separate octave sessions. Also, at least some of the non-octave differences are due to trivial glyph id changes, i.e., when I looked at the java differences for example 24 two glyphs had the same contents as the corresponding C result, but different names, and when the name differences were accounted for, the order of the glyph definitions in the header of the svg file was different between java and C. (Are these glyph changes perhaps due to different threads taking longer/shorter for each different language?) In sum, I think the svgcairo test device is telling us a lot about pango/cairo library idiosyncrasies but nothing useful about PLplot issues so I intend to ignore svgcairo from now on and instead stick with the default svg test device choice since that does give a perfect difference report. M examples/octave/x14c.m M examples/octave/x31c.m M plplot_test/test_octave.sh.in commit 9f53302538879a7113b11de822dd917fda38ac2d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Oct 8 01:24:29 2018 -0700 Build system upgrade: Generalize how test_diff.sh is implemented and used in our test frameworks The test_diff.sh(.in) configured script has long been implemented to allow comparing results for our standard set of 33 examples implemented in any of our language bindings with corresponding C results as a test of the PLplot API consistency for each of our language bindings. Up to now that script was configured to allow either psc or svg as the device used for the comparison of plot file results with rather specific implementation details for the familied (separate files for separate pages of examples) svg device. The svg alternative was only usable for our CTest-based test framework (through the user specifying -DPLPLOT_TEST_DEVICE=psc or -DPLPLOT_TEST_DEVICE=svg) with our CMake-based and traditional (based on Makefiles + pkg-config) test frameworks completely ignoring this potential choice and always using psc for the comparisons instead. With this commit all these limitations concerning test_diff.sh have been removed. If the user makes an error so that the specified PLPLOT_TEST_DEVICE does not correspond to a enabled file device then the build-system response to this error is that test_diff.sh will be unused by our three test frameworks. But if PLPLOT_TEST_DEVICE corresponds to an enabled file device, then whether this device is familied is automatically detected by the build system, and the device and familied information passed on to the updated test_diff.sh via the --device and (new) --familied_device options. The updated test_diff.sh implementation automatically accounts for all device and familied details depending on the values of those two options. And test_diff.sh is run in the same way for all our three (CMake-based, CTest-based, and traditional) test frameworks. In sum, users should be able to specify (via PLPLOT_TEST_DEVICE) any enabled file device, and all our standard examples in all supported languages should be run for that device with results compared by test_diff.sh for any or all of our three test frameworks. N.B. An important change for this commit is to use "svg" rather than "psc" as the default value of PLPLOT_TEST_DEVICE. These two devices share the advantage of having no dependencies and thus being immediately available on all platforms. The SVG XML format of the plot file output by the svg device file constitutes a small advantage over the PostScript format of the plot file output of the psc device because (at least in this author's opinion) SVG XML is fundamentally easier for humans to learn than PostScript. But an even stronger advantage of the svg device is it is a modern PLplot device that implements alpha-channel transparency and gradients and which gives access to virtually all (unicode-accessible) glyphs installed on a platform while the psc device is an ancient PLplot device that because of the limitations of PostScript is missing the alpha-channel and gradient capabilities and which only gives access to an extremely limited number of glyphs. Thus, when the svg device is used for comparisons, test_diff.sh compares one good plot file result with another for essentially all examples (see below for the one exception), but when the psc device is used for comparisons test_diff.sh compares one garbage plot file with missing or incorrect elements with another for many of our standard examples. This means the svg default choice we have adopted supplies a much stronger constraint on our language PLplot API consistency than the old psc default. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by running time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no --do_submit_dashboard yes) once to test the default case of the complete set of Linux devices with the default PLPLOT_TEST_DEVICE=svg and time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DDEFAULT_NO_DEVICES=ON -DPLD_<device_name>=ON -DPLPLOT_TEST_DEVICE=<device name>" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no) 7 different times with <device_name> set to ps, psc, psttf, psttfc, svg, svgqt, or svgcairo to test the case when the indicated devices were enabled individually. I also ran this test again for the svgqt case and -DENABLE_octave=OFF. The first of these comprehensive tests yielded three good dashboard results (corresponding to the ctest execution in the core build tree for our 3 major configurations) at <https://my.cdash.org/index.php?project=PLplot_git> on 2018-10-07. I took a look in detail at the svg results and the results for all examples other than example 3 rendered correctly when viewed with the eog SVG browser. So as referred to above, svg is much better in this regard than psc which has badly rendered results for quite a large number of our examples because of the limitations of PostScript. The svg issue with example 3 is that certain graphical elements are missing consistently for all our supported languages. They are also missing if that example is viewed with other SVG browsers such as the konqueror and firefox browsers and the "display" application available from the ImageMagick software suite (which by the way only works correctly for SVG if inkscape is installed as well.) Those elements for example 3 are also missing for the svgqt and svgcairo devices so it is certainly possible that our fundamental C API implementation that is exercised directly by C standard example 3 (and also indirectly by our other language bindings and example 3 implementations in those languages) is attempting to draw the missing graphical elements of this example in a way that is not compatible with the SVG standard. But a lot more investigation and a much-simplified test example will likely be required to figure that out. The total of the 9 different comprehensive tests above were evaluated in the usual manner (see previous commit messages for details and also a future commit for README.testing which will document the usual evaluation procedure for comprehensive test results). In all but two cases there were no configuration or run-time issues with these comprehensive tests. Those two exceptions were the following: 1. Intermittent javac segfault. This only happened one time, and I could never replicate it afterwards. However, a valgrind run (with the recommended for java --smc-check=all option to allow valgrind to follow all self-modifying code changes that apparently are common for java) for exactly the same (openjdk) javac command that segfaulted when compiling x27.java into byte code showed 10 million memory management issues before valgrind reached its limits and quit checking any further. So it appears the openjdk javac command is potentially a rich source of segfaults, and the only surprise is how little it happens! In any case, I don't think this is our problem so if I ever run into this issue again, I will simply repeat the test with a good chance it will succeed. 2. Repeatible errors with the combination of svgqt and octave On Debian Buster at least, octave examples and the svgqt device (or any other qt device) are a toxic combination with consistent error messages typically like: (process:17721): GLib-CRITICAL **: 13:36:35.133: g_main_context_pop_thread_default: assertion 'g_queue_peek_head (stack) == context' failed double free or corruption (out) fatal: caught signal Aborted -- stopping myself... From <https://bugs.launchpad.net/calibre/+bug/1022019> it appears similar errors for the calibre software project were generated by glib library inconsistencies. However, from ldd -r on bindings/octave/plplot_octave.oct and other evidence it appears that octave does not depend on libglib so perhaps there is something about the octave examples that exposes a bug in libqt or else a bug in the qt device driver. Anyhow, I plan to investigate this issue further by attempting to determine which octave example generates the above message. There were a large variety of plot different reports for the additional wide range of test device possibilities enabled by this commit. For PLPLOT_TEST_DEVICE=psc or ps, the difference report was perfect (i.e., this commit has not introduced any regressions into the psc result used before, and ps follows that perfect result.) For PLPLOT_TEST_DEVICE=psttfc or psttf the difference report was octave Missing examples : Differing graphical output : 07 24 Missing stdout : Differing stdout : For PLPLOT_TEST_DEVICE=svg the difference report was octave Missing examples : 14a 31 Differing graphical output : Missing stdout : Differing stdout : For PLPLOT_TEST_DEVICE=svgcairo the difference report was java Missing examples : Differing graphical output : 24 Missing stdout : Differing stdout : octave Missing examples : 14a 31 Differing graphical output : 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 33 Missing stdout : Differing stdout : python Missing examples : Differing graphical output : 09 24 Missing stdout : Differing stdout : tcl Missing examples : Differing graphical output : 03 14a 24 Missing stdout : Differing stdout : For PLPLOT_TEST_DEVICE=svgqt with -DENABLE_octave=OFF the difference report was ocaml Missing examples : Differing graphical output : 28 Missing stdout : Differing stdout : In sum, the generalization of the test_diff.sh testing provided by this commit provides a powerful new tool to expose issues with our bindings and or standard examples for each of our supported languages. The above difference report results show no regressions with the previous psc results and constitute the best new difference reports we can generate at the present time and are a benchmark for future changes for all the new diff report test devices that are enabled by this commit. Of course, it is also obvious from these results there is clearly a lot of of work to do (especially for the octave binding and examples) to reach an important new goal motivated by this commit which is difference-free results for all languages for all these different test devices. M cmake/modules/drivers-finish.cmake M cmake/modules/plplot.cmake A cmake/modules/test_diff.cmake M examples/CMakeLists.txt M examples/Makefile.examples.in M examples/plplot_configure.cmake_installed_examples.in M plplot_test/CMakeLists.txt M plplot_test/test_diff.sh.in M plplot_test/test_octave.sh.in commit 115cedd8378bf7627263f0f2c2d7831a0714566a Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Oct 5 16:40:51 2018 -0700 Configure both the ps and psttf device drivers like all other device drivers Previous to this commit the ps device driver configured its devices (i.e., the ps and psc devices) together rather than individually and the same for the psttf device driver and the corresponding psttf and psttfc devices. All other device drivers configured their devices individually and this anomalous ps and psttf situation generated a lot of extra build-system complexity. We inherited this bad situation from our previous autotools-based build system and never addressed this issue until this commit which configures both the ps and psttf device drivers to implement individual devices just like all the rest of our device drivers. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by running time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no) once to test the default case of the complete set of Linux devices and time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DDEFAULT_NO_DEVICES=ON -DPLD_<device_name>=ON" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no) 5 different times with <device_name> set to ps, psc, psttf, psttfc, and svg to test the case when the invidual devices for the ps and psttf device drivers were enabled and when none of the devices for the ps and psttf device drivers were enabled. These 6 different comprehensive tests were evaluated in the usual manner (see previous commit messages for details and also a future commit for README.testing which will document the usual evaluation procedure for comprehensive test results). In all cases there were no configuration, run-time, or PostScript difference (when the psc device was implemented) issues detected so I feel confident that the current set of rather intrusive changes has introduced no regressions. M cmake/modules/drivers-init.cmake M cmake/modules/pstex.cmake M cmake/modules/psttf.cmake M drivers/ps.c M drivers/ps.driver_info.in M drivers/pstex.c M drivers/psttf.cc M drivers/psttf.driver_info.in M examples/CMakeLists.txt M examples/Makefile.examples.in M include/drivers.h M include/plDevs.h.in M include/plcore.h M include/ps.h M plplot_test/CMakeLists.txt M plplot_test/plplot-test.sh.in commit 58df034d4ea4682d911b419e296819aa5a8ba242 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Oct 5 16:03:28 2018 -0700 Build system: Fix undefined LIB_INSTALL_RPATH bug for the Python binding In bindings/python/CMakeLists.txt we determined and immediately used LIB_INSTALL_RPATH in a first context but used that value in a second context as well. And the conditions of that second context differed sometimes (e.g., if only a single device was enabled) from that first context leaving LIB_INSTALL_RPATH undefined for that second context. I fixed this bug by determining and immediately using LIB_INSTALL_RPATH independently for the second context. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by running scripts/comprehensive_test.sh for a single device (svg) without issues. Details of this and other tests I ran will be given for the next commit. M bindings/python/CMakeLists.txt commit e36a423fe0927987119bb94459750039737b47f3 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 26 01:49:27 2018 -0700 Remove unused data/.dummy file git log --follow -- data/.dummy shows this empty file was originally committed in 1992 with a comment that it was a placeholder, but nothing has been done with it since other than to change its directory location. Therefore, the current removal is long overdue. D data/.dummy commit 2682d15f9ffd6b53e630e6c9b35200680dea2ed3 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 26 00:48:00 2018 -0700 Fix external URL references for the website I completely checked every external URL reference for our website and found only the HomeBrew reference on the Downloads page and the libgd reference on the Credits page were dead/invalid. This commit updates those references to valid sites again. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster> by following the (recently updated) instructions in README.Release_Manager_Cookbook to regenerate the local website, and then I checked that website to make sure the above two references linked to the desired sites. M www/credits.php M www/downloads.php commit cf236a23c28c17dbf9e53667a9c7488d4ac357c9 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 26 00:25:20 2018 -0700 Update scripts and instructions for generating local version of website The scripts to help generate the website were updated with commentary tweaks and an update to all make commands to use the PARALLEL_BUILD_OPTION bash variable which was set to "-j10" at the start of each script. This value is suitable for my new hardware with 8 cores but could easily be modified by someone else with different hardware whenever I step down as release manager. I updated the instructions for the apache install and configuration and instructions for the website generation for the release manager in README.Release_Manager_Cookbook. That file was also updated with all references to "raven" (my old computer) replaced by "merlin" (my new computer) and all references to Debian Jessie (the Debian version on my old computer) replaced by Debian Buster (the Debian version on my new computer). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by following the above apache install and configuration instructions and the above website generation instructions. I did not do any of the detailed error checking that is recommended for a release, but the result appeared to be a valid local website that I could easily browse with the konqueror and firefox browsers. M README.Release_Manager_Cookbook M scripts/generate_website.sh M scripts/htdocs-gen_plot-examples.sh commit 8fdfe5cabd5320e9787583fcd2e984cb4bb14dbf Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Sep 23 23:57:27 2018 -0700 Report PostScript difference results in alphabetical order of languages Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the test_diff_psc target and confirming the (perfect) PostScript difference report is now alphabetized by language. M plplot_test/test_diff.sh.in commit d6a76270499d393452df5cf36255bed2693891b3 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Sep 23 22:59:55 2018 -0700 Build system: for Mac OS X drop user overide that imposes the dated -single_module linking option Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot with cmake with no errors due to this change. However, that is just a minimal test (since this removed override was a no-op on Linux) so the definitive test of this change is requested on Mac OS X platforms. M CMakeLists.txt D cmake/UserOverride.cmake commit d2d9461a3ce3516c98611852879467e5cf0b8265 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Sep 22 16:40:32 2018 -0700 Build system: allow consistent use of a build of Lua that is installed in a non-standard location I also made the cmake messages emitted by the Lua part of the configuration more informative. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot using env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 "/home/software/cmake/install-3.7.2/bin/cmake" ... where /home/software/lua/install-5.3.5 is the install prefix of a local build of Lua-5.3.5 The result was consistent non-system versions of the lua library and executable were found. Furthermore, I tested that result using make -j10 test_diff_psc >& test_diff_psc.out with no build or run-time errors and a perfect PostScript difference report (for all components including lua). M cmake/modules/lua.cmake commit 4a5f94a70ac259d696dfaa8117cead7ad89b13f3 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Sat Sep 22 11:57:05 2018 +0100 Changed order of some wxwidgets headers to avoid compilation bug Compile errors of wxwidgets_dev.cpp were reported on vs2017 by Laurent Berger, with many errors looking like 1>c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\ws2def.h(235): error C2011: 'sockaddr': 'struct' type redefinition 1>c:\program files (x86)\windows kits\10\include\10.0.16299.0\um\winsock.h(1007): note: see declaration of 'sockaddr' 1>c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C2059: syntax error: 'constant' 1>c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C3805: 'constant': unexpected token, expected either '}' or a ',' You can find the discussion on the plplot-devel mailing list with title cannot compile plplot using vs 2017. The suspicion is a wierd interaction with the wx headers and the windows.h header included in our wxwidgets_comm.h file. It seems that ensuring wx/wx.h is included before windows.h avoids the problem. M drivers/wxwidgets.h commit caf4801dfef32207b74f5374eff52bf2a4c24e3d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Thu Sep 20 22:36:48 2018 -0700 Build system: Improve logic for finding Lua There are two improvements: * Instead of blacklisting Lua5.3 (due to what turns out to be a run-time issue for that version of Lua that occurs on Debian Buster but not Fedora) do the following: If the user has specified REQUIRED_LUA_VERSION on the command line (e.g. -DREQUIRED_LUA_VERSION=5.2 to avoid 5.3), then search specifically for that version of Lua. Otherwise, do a search for Lua without specifying a version which means CMake will find the latest version of Lua that is installed. * If possible find the lua executable using the versioned name, e.g., "lua5.2" that is consistent with the Lua version found, but if that versioned name is not found, then find the unversioned name "lua" of the executable as a last resort. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by running cmake with various values (or none) of -DREQUIRED_LUA_VERSION to make sure a consistent version of Lua is found in all cases (or no version is found if the REQUIRED_LUA_VERSION string does not correspond to an installed version of Lua). M cmake/modules/lua.cmake commit a9d9500c732d4eae47ed7fca687e02ec8a48d02c Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 19 16:38:53 2018 -0700 Build system: Future-proof use of FindPkgConfig by replacing call to _pkg_check_modules_internal with pkg_check_modules The previous use of _pkg_check_modules_internal was "an accident waiting to happen" since such logic obviously depends on an internal implementation detail of CMake's FindPkgConfig module while pkg-check_modules is for public use and therefore more stable. And although CMake-3.12.2 was fine in this regard, that accident did happen for the git version of CMake that will turn into version 3.13.0, and this commit solves this "future" issue. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster on my AMD Ryzen 7 1700 box) by running time (nice -19 env PATH="/home/software/cmake/Dashboards/Scripts/My Tests/CMake-build/Tests/CMakeInstall/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "ctest -j10") The combination of running the script from a source tree with blanks in the prefix (see above invocation) and the above --prefix option containing a blank tests that the current build system continues support for blanks in source-, build-, and install-tree prefixes; and the "-DUSE_INCRTCL_VERSION_4=ON" cmake option is appropriate for the software versions of Tcl/Tk/Itcl/Itk/Iwidgets that I have installed from Debian Buster. Furthermore, I only have Qt5 development packages installed so only the Qt5 version of the qt device driver is tested here. The above setting of PATH accesses the git (CMake commit ddb33b) version of CMake and CTest that was tested successfully by hand using the PLplot contract build test earlier today. However, the above test does a lot more than that simple PLplot build and install test so it is much more "comprehensive" test both of PLplot and CMake. The above script ran both interactive and noninteractive tests for direct use of my graphics card (i.e., not for an X-terminal) and completed (in 46 minutes) without running into any hangs or non-zero return codes, and the accompanying test results were evaluated as follows: # Check for all errors where that last pipeline stanza is to ignore # normal "ldd" references to the gpg-error library and normal "make # clean" references to test.error: grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libgpg-error.so|test.error' # Check for regressions in configuration warnings: grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries' # Check for regressions in the distinct run-time warning labelled by 'PLPLOT WARNING': grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u # Check for build or run-time warnings where the trailing stanza is to # remove the "PLPLOT WARNING" and cmake.out warnings investigated # above, and spurious gfortran warnings: find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic' # Check for any ldd issues for the shared and nondynamic cases: grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out # Check for any PostScript or Text differences between all non-C # languages and the corresponding C results: grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less In sum, these checks of the above comprehensive test results showed no configure, build, run-time, or PostScript difference issues for the "future" version of CMake that was tested. M cmake/modules/cairo.cmake M cmake/modules/pkg-config.cmake commit a730ebe34b9edd44124e0d217672e678ddd06eca Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Sep 15 02:38:42 2018 -0700 Build system: fix OCaml build warnings for installed examples Previously there were warning messages emitted by Debian Buster (but not Debian Jessie) ocamlopt when linking the installed OCaml examples. These warnings took the following form: Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque This commit solves this issue by installing plplot.cmx (as implied by the above warning message). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster on my AMD Ryzen 7 1700 box) in exactly the same way as my previous commit with only one change in the evaluation of the comprehensive test results, namely the above warning messages no longer occur. Therefore, as far as I know, this commit removes the last "modern software" issue caused by building and testing PLplot in a Debian Buster = Testing environment rather than Debian Jessie = Oldstable environment that I was using for testing before. M bindings/ocaml/CMakeLists.txt commit b10135855e7c2ae322a4fb4079398ff84eef80db Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Sep 14 15:18:06 2018 -0700 Build system: fix regression in linking of libplplotqt This commit once again links libplplotqt with the plplot and math libraries for the Qt5 case to fix a regression introduced by my recent work on prefixing all the installed targets. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster on my AMD Ryzen 7 1700 box) by running time (nice -19 "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/home/software/cmake/install-3.7.2/bin/cmake" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/home/software/cmake/install-3.7.2/bin/ctest -j10" --do_test_interactive no) The combination of running the script from a source tree with blanks in the prefix and the above --prefix option containing a blank tests the current build system continues support for blanks in source-, build-, and install-tree prefixes; and the "-DUSE_INCRTCL_VERSION_4=ON" cmake option is appropriate for the software versions of Tcl/Tk/Itcl/Itk/Iwidgets that I have installed from Debian Buster. Furthermore, I only have Qt5 development packages installed so only the Qt5 version of the qt device driver is tested here. The above script completed (in 19 minutes) without running into any hangs or non-zero return codes, and the accompanying test results were evaluated as follows: # Check for all errors where that last pipeline stanza is to ignore # normal "ldd" references to the gpg-error library and normal "make clean" # references to test.error. grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libgpg-error.so|test.error' # Check for regressions in configuration warnings: grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries' # Check for regressions in the distinct run-time warning labelled by 'PLPLOT WARNING': grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u # Check for build or run-time warnings where the trailing stanza is to # remove the "PLPLOT WARNING" and cmake.out warnings investigated above, # and spurious gfortran warnings: find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic' This test revealed the following warning message regression which was a number of different instances of the following message: Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque This warning which I attribute to a new version of OCaml for Debian Buster appears to not have any practical consequences (e.g., the clean PostScript differences reported below). Nevertheless, I plan to investigate this warning at a later time. # Check for any ldd issues for the shared and nondynamic cases. grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out No issues were found, i.e., this commit solves the regression in this regard found by the last several comprehensive tests. # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results: grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less In sum, these checks of the above comprehensive test results showed no configure, build, run-time, or PostScript difference issues other than the noted regression in non-consequential OCaml warnings which I will investigate later. M bindings/qt_gui/CMakeLists.txt commit 0583fe8feb335c147f7951fe1bb4eb5e93a56317 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Sep 9 14:15:35 2018 -0700 Build system: fix a bug in the use of the <TARGET_FILE:PLPLOT::pltcl> and $<TARGET_FILE:PLPLOT::plserver> generator expressions The fix was to use these generator expressions only when ENABLE_tkX was true since the shell script being configured only uses these locations for that case. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by setting the DISPLAY environment variable to nothing before configuring PLplot. (An incorrect setting of DISPLAY in a crontab task to submit a PLplot contract dashboard for CMake first exposed these bugs). For incorrect DISPLAY the Tk configuration of PLplot fails (softly) with the result that ENABLE_tkX is false, which means with this fix in place that the <TARGET_FILE:PLPLOT::pltcl> and $<TARGET_FILE:PLPLOT::plserver> generator expressions are not used which avoids the build-system error that occurred before this fix. M plplot_test/CMakeLists.txt commit 7ec926fae5e17cbfc9ebb4c83144a8c7ef177cbb Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Sep 9 03:42:06 2018 -0700 D examples: adjust so they compile for gcd-8 These adjustments for the 21st example were to replace isnan by isNaN, and for the 31st example were to drop importation of std.cstream (because cstream no longer exists in libphobos for gdc-8) and to replace derr.writefln by stdderr.writefln everywhere. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by installing the gdc-8 and gnat-8 packages (to be consistent with the gcc-8 version being used) and running time (nice -19 "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/home/software/cmake/install-$CMAKE_VERSION/bin/cmake" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_interactive no) with CMAKE_VERSION = 3.7.2, 3.11.0, or 3.12.2 for a total of 3 script invocations. The combination of the above three invocations of the script from a software tree with blanks in the prefix and the above --prefix option containing a blank tests the current build system continues to test support for blanks in source, build, and install tree prefixes; the three versions of CMake correspond to the minimum version for the Linux platform, the minimum version for non-Linux platforms, and the latest current version of CMake; and the "-DUSE_INCRTCL_VERSION_4=ON" cmake option is appropriate for the software versions of Tcl/Tk/Itcl/Itk/Iwidgets that I have installed from Debian Buster. All three test script invocations completed without running into any hangs or non-zero return codes, and the accompanying test results were evaluated in each of the 3 cases as follows: # Check for all errors: grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libG|libgpg-error.so' where that last pipeline stanza is to ignore routine libGL error messages issued by my X-terminal box and to ignore normal ldd references to the gpg-error library. # Check for regressions in configuration warnings: grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries' # Find each distinct run-time warning labelled by 'PLPLOT WARNING': grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u # Check for build or run-time warnings: find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out|opaque' where the trailing stanza is to remove "PLPLOT WARNING" issues, spurious gfortran warnings, cmake.out warnings, and a number of instances of Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque which appears, see below, to not have any consequences for the OCaml case. Nevertheless, I plan to investigate this warning further. # Check for any ldd issues for the shared and nondynamic cases. grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out I found a number of these for modern (Debian Buster) software which I plan to investigate later. # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results: grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less These checks of the above comprehensive test results showed no configure, build, run-time, or PostScript difference issues. Thus, the install of gnat-8 seems to have solved all gnatmake parallel build issues I encountered before, and the install of gdc-8 (along with the above adjustments of the D examples) also appears to have worked perfectly. M examples/d/x21d.d M examples/d/x31d.d commit 15d5829b94d79afbcddce3bd168dded0bcf85fa4 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Sep 9 01:56:03 2018 -0700 PLplot build system: bump minimum CMake version from 3.6.2 for all platforms to 3.7.2 for the Linux platform and 3.11.0 for non-Linux platforms The motivation for these changes is to reduce build-system bugs by forcing our users to use modern CMake (especially on non-Linux platforms where older versions of CMake can be problematic). With one exception, these minimum version choices mean that PLplot users on modern Linux platforms and the major modern non-Linux platforms should be able to rely on the official versions of CMake for those platforms. The exception to this PLplot user convenience is Cygwin where the CMake packaging effort there has become moribund (i.e., stuck on CMake 3.6.2 for much too long a time for what is supposed to be a rolling release that keeps up with the latest free software versions). Because of this packaging problem for CMake on Cygwin, this PLplot change means our Cygwin users will need to build their own CMake with version = 3.11.0 or greater before they build PLplot. See also the commentary in the top-level CMakeLists.txt file for details of the web sites checked for the CMake version that is officially installed for various platforms. I also took this opportunity to bump the minimum CMake version for other minor projects within the PLplot source tree to 3.7.2 or 3.11.0 depending on whether for those projects I wanted to follow the minimum version adopted for PLplot for either the Linux platform or non-Linux platforms. M CMakeLists.txt M cmake/modules/language_support.cmake M cmake/modules/language_support/cmake/CMakeTestAdaCompiler.cmake M cmake/test_ada/CMakeLists.txt M cmake/test_ada/cmake/Modules/CMakeTestAdaCompiler.cmake M cmake/test_ada/installed_CMakeLists.txt M cmake/test_automoc/CMakeLists.txt M cmake/test_fortran/CMakeLists.txt M cmake/test_fortran/installed_CMakeLists.txt M cmake/test_linux_ipc/CMakeLists.txt M examples/CMakeLists.txt commit d4ac55ea76fc7f5b514bc6e454b4c599dc048fde Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Sep 8 22:18:40 2018 -0700 Build system: Blacklist Lua 5.3 At least for Debian Buster, Lua 5.3 has a severe bug (see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238>). We previously worked around this upstream Lua-5.3 bug by dropping Lua example 23 (the only example that exposes this bug) from our tests, but for this commit we restore Lua example 23 for our tests, and simply blacklist Lua 5.3 instead. As a result of this change we now support only Lua 5.1 and 5.2 (preferred if both 5.1 and 5.2 are available). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by installing Lua 5.2 and building the test_diff_psc target in the build tree (for the default shared library and dynamic devices case) for CMake versions 3.7.2, 3.11.0, and 3.12.2 where the first two versions are of future importance to our build system (respectively the planned minimum versions of CMake for Linux and non-Linux systems) and the third version is the current latest CMake version. All results from these test_diff_psc builds showed no obvious configure, build, or run-time issues, and the PostScript difference results were perfect again because of restoration of Lua example 23 to our tests and the use of Lua 5.2 for both our Lua binding build and tests of our Lua examples. M cmake/modules/lua.cmake M plplot_test/test_lua.sh.in commit 5c31678babaf99da755f48ef103aefe05c39a38c Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Sep 8 19:10:23 2018 -0700 Build system bug fix: set correct source file property on lib/csa/csa.c Previously when gcc was the C compiler, I set the source file property COMPILE_OPTIONS for lib/csa/csa.c to -fno-inline-functions to work around what appears to be an issue with gcc version 7.3.0-21 and now also 8.2.0 (where both versions tested were from Debian Buster) where the explicit (or implicit via -O3) use of the -finline-functions gcc option caused segfaults in the libcsirocsa library. And this workaround was well-tested for CMake-3.11.x from Debian Buster. However, it turns out that COMPILE_OPTIONS is not recognized as a source file property for CMake-3.10.x and earlier so the workaround failed for those versions of CMake. This commit fixes this issue by setting the COMPILE_FLAGS rather than COMPILE_OPTIONS source file property to specify the -fno-inline-functions gcc option. This should work for all CMake 3.x versions (although COMPILE_FLAGS is deprecated from CMake-3.11.x on). Because of that deprecation, the plan is to switch all mentions of COMPILE_FLAGS to COMPILE_OPTIONS once our minimum version of CMake on all platforms is 3.11.0 or higher. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the test_diff_psc target in the build tree (for the default shared library and dynamic devices case) for CMake versions 3.7.2, 3.11.0, and 3.12.2 where the first two versions are of future importance to our build system (respectively the planned minimum versions of CMake for Linux and non-Linux systems) and the third version is the current latest CMake version. All results from these test_diff_psc builds showed no obvious configure, build, or run-time issues, and there were no regressions in the PostScript difference results. M lib/csa/CMakeLists.txt commit e298aa70a1f5e30c55cbfd26488432ca17b1b75f Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Aug 26 12:32:49 2018 -0700 Build system: Implement NAMESPACE PLPLOT:: prefix for all installed targets This commit is the culmination of my previous work on core build prefixes (ALIASed PLPLOT:: prefix for read-only targets and the normally empty except when -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON ${WRITEABLE_TARGET} prefix for writeable installed targets) for all targets that will be installed. Because of that previous work, and especially the core build tests that succeeded with-DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON proving all installed targets (*for CMake code that was exercised in those tests*) were prefixed, this commit ideally should have just contained one change (to use the NAMESPACE PLPLOT:: signature for the "install(EXPORT export_plplot ...)" CMake command. However, the previous work (notably commit 0df4e30e6b on 2018-04-06) that implemented the core build change to use the PLPLOT:: prefix when referring to read-only targets meant that the installed version of PLplot could not be tested from then until now. So this commit includes the following bug fixes for the installed version of PLplot: Prefix-related fixes: Change Tcl tests for CMake-based build system for installed examples from source tree to build tree. This fix was needed because all the examples/c/x?? scripts became configured as part of the prefix changes. At the same time the Tcl tests for the traditional build system for the installed examples are still for the case where source and build trees are the same so the core build system must configure examples/c/x?? script for this additional case as well. Fix blank-in-path quoting issues introduced by using configured target locations in plplot_test/plplot-test-interactive.sh(.in). Debian Buster versus Jessie fixes: The Debian Buster version of Qt5 demands that all executables (i.e. qt_example) that specifically links to the Qt5 libraries must be built with a special option (e.g., -fPIC on Linux systems). This happens automatically for targets configured by CMake, but I had to change pc_qt_COMPILE_FLAGS to accomodate this need for our traditional (make and pkg-config) build system for the installed examples. Other fixes and improvements: Fixed bug for corner case where ENABLE_tkX was true and xwin_targets was false. Fixed bug where needed DROP_GTK_PLUS_2_BUILDS was not propagated to the CMake-based build system for the installed examples. Replaced EXAMPLES_DIR and SRC_EXAMPLES_DIR environment variable misnomers (and corresponding --examples-dir and --src-examples-dir script option misnomers) throughout our build system and test scripts by EXAMPLES_PREFIX and SRC_EXAMPLES_PREFIX (and corresponding --examples-prefix and --src-examples-prefix script options). Wrote plplot_test/README.developers to document test scripts. This documentation includes a much-needed explanation of how EXAMPLES_PREFIX and SRC_EXAMPLES_PREFIX are used. Added maintenance section to drivers/README.drivers to show how to make certain that the driver id numbers are unique and driver information is consistent. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by running "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/usr/bin/cmake" --cmake_added_options "-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" where the combination of the above launch of the script from a software tree with blanks in the prefix and the above --prefix option containing a blank tests the current build system continues to test support for blanks in source, build, and install tree prefixes; the /usr/bin versions of cmake and ctest are the Debian Buster versions with version number of 3.11.2; and the "-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON" cmake options are appropriate for the software versions of (buggy) gnatmake and Tcl/Tk/Itcl/Itk/Iwidgets that I have installed from Debian Buster. The first invocation of the above command failed for the CMake-based interactive tests of the installed examples tree. The failure message stated that a test was run using -dev plmeta (which, of course, should not work since that device is disabled by default and I double checked that was the case for this particular invocation of the comprehensive test script. This error is an intermittent one (three attempts to replicate it afterwards including a second invocation of exactly the same command failed to show the error). Furthermore, the error message is inexplicable since the confirmed disablement of the device should mean the device was not used for testing for anything, and the fact that it is a noninteractive device means it should not have been used for interactive testing in any case! So this is indeed a nasty puzzle, but I plan to wait until the bug triggers again to investigate it further. This (second) test script invocation completed without running into any hangs or non-zero return codes, and the accompanying test results were evaluated as follows: # Check for all errors: grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libG|libgpg-error.so' where that last pipeline stanza is to ignore routine libGL error messages issued by my X-terminal box and to ignore normal ldd references to the gpg-error library. # Check for regressions in configuration warnings: grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries' # Find each distinct run-time warning labelled by 'PLPLOT WARNING': grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u # Check for build or run-time warnings: find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out' where the trailing stanza is to remove "PLPLOT WARNING" issues, spurious gfortran warnings and cmake.out warnings. This yielded a number of instances of the following warning Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque which appears, see below, to not have any consequences for the OCaml case. Nevertheless, I plan to investigate this warning further. # Check for any ldd issues for the shared and nondynamic cases. grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out I found a number of these for modern (Debian Buster) software which I plan to investigate later. # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results: grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less There is a well-known upstream issue with lua5.3 software that is exposed by lua example 23 which we have worked around by dropping that example from the PostScript comparison test, but otherwise these checks of the above comprehensive test results showed no configure, build, run-time, or PostScript difference issues. M cmake/modules/plplot_functions.cmake M cmake/modules/qt.cmake M doc/docbook/README.developers M drivers/README.drivers M drivers/wingdi.driver_info.in M examples/CMakeLists.txt M examples/plplot_configure.cmake_installed_examples.in M examples/tcl/CMakeLists.txt M examples/tk/CMakeLists.txt M plplot_test/CMakeLists.txt A plplot_test/README.developers M plplot_test/plplot-test-interactive.sh.in M plplot_test/plplot-test.sh.in M src/CMakeLists.txt commit beba481633e7ce148fc33386464b6a1b23f2b59b Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Aug 3 23:32:11 2018 -0700 Style previous commit M plplot_config.h.in commit dd9699e5628309d4ee4a264d989c0868f5ef3dcd Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Aug 3 23:17:03 2018 -0700 Comprehensive test script: fix blank in fullpath bug The dirname logic used to obtain SCRIPT_PATH needed to be modified (using quotes) when the script was invoked using a fullpath to the script that included a blank, e.g., "../plplot blank .git"/scripts/comprehensive_test.sh" .... used to invoke the script in the test of the last commit. Tested by: Alan. W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) with the script invocation described above. M scripts/comprehensive_test.sh commit 94b5cf188d92b11920ad1998eda910e6e91992ae Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Aug 3 23:10:41 2018 -0700 Build system: Finish the topic concerning special target prefixes for the build tree The add_executable and add_library targets that are built in the build tree and installed (as opposed to built) in the install-tree are special targets where special build-system rules are needed. Best CMake practice is to install such special targets in name-spaced form (i.e., with a target prefix of PLPLOT::). Because common CMake files are used by both the build-tree and installed-examples build systems, this also means that ALIASed targets with prefix PLPLOT:: must be defined in the build-tree build system for common targets for the two build systems. Those common targets are read-only so for uniformity I have defined ALIASed targets to be used for all build-tree, read-only, special target cases. And to make sure no unprefixed read-only special targets are left, I have also for the build-tree case used the ${WRITEABLE_TARGET} prefix for all special targets which are not read-only. The side effect of this is all the associated executable and libraries files also have the same ${WRITEABLE_TARGET} prefix appear in their core name. Of course, you do not normally want that side effect so WRITEABLE_TARGET is undefined for the (default) case where -DUSE_WRITEABLE_TARGET_TEST_PREFIX=OFF. However, if the build-tree build system user specifies -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON, then all unprefixed special targets *that are used in executed CMake code* (which is an important caveat) will generate a cmake error which will identify most but not necessarily all (because of that caveat) unprefixed special targets that still need to be addressed. A previous commit implemented such special target logic for all libraries, modules, and swig modules while this commit completes that work by dropping the hershey library (which does not qualify since it is not installed) from that list, and implementing such special target logic for the executables that qualify, i.e., just plserver, pltcl, plrender, pltek, and wxPLViewer. In addition this commit changed many build system names committed as part of the previous prefix work that became obvious misnomers for this present case where special targets refer to both add_executable and add_library targets that qualify. Because of these name changes, this commit is quite intrusive. N.B. This commit completes the topic of special target prefixes for the build-tree case. And the test below (which uses -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON) applies to just the build-tree case alone. I haven't considered it yet in detail, but, it is possible the installed results of the -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON case (where all the core names of relevant libraries and executables are prefixed) might be usable with some additional modifications. If so; I might implement such modifications so that the -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON case works for all of build-tree, installed examples tree, and traditional installed examples tree cases; but only if the benefits justify the work involved. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by running "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/usr/bin/cmake" --cmake_added_options "-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_install_tree no --do_test_traditional_install_tree no --do_submit_dashboard no) where the combination of the above launch of the script from a software tree with blanks in the prefix and the above --prefix option containing a blank tests the current build system continues to support blanks in source, build, and install tree prefixes; the /usr/bin versions of cmake and ctest are the Debian Buster versions with version number of 3.11.2; the "-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON" cmake options are appropriate for the software versions of (buggy) gnatmake and Tcl/Tk/Itcl/Itk/Iwidgets that I have installed from Debian Buster; -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON tests special executable library and target names as I have explained above; and although (by default) both interactive and noninteractive comprehensive tests were done, I dropped all but build-tree tests for the reasons explained above. This test script invocation completed without running into any hangs or non-zero return codes, and the accompanying test results were evaluated as follows: # Check for all errors: grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -v libGL where that last pipeline stanza is to ignore libGL error messages issued by my X-terminal box. # Check for regressions in configuration warnings: grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries' # Find each distinct run-time warning labelled by 'PLPLOT WARNING': grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u # Check for build or run-time warnings: find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out' where the trailing stanza is to remove "PLPLOT WARNING" issues, spurious gfortran warnings and cmake.out warnings. # Check for any ldd issues for the shared and nondynamic cases. # N.B. commented out this time because the above comprehensive_test.sh options # (--do_test_install_tree no --do_test_traditional_install_tree no) # preclude checking for ldd issues so there are no *.ldd.out files to # check. #grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results: grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less There is a well-known upstream issue with lua5.3 software that is exposed by lua example 23 which we have worked around by dropping that example from the PostScript comparison test, but otherwise these checks of the above comprehensive test results showed no configure, build, run-time, or PostScript difference issues. Because this test was a success with the above -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON cmake option, it appears there continues to be no special executable or library target references without prefixes (PLPLOT:: for read-only special targets and ${WRITEABLE_TARGET} for writeable special targets) for the CMake logic exercised by the above tests. M CMakeLists.txt M bindings/ada/CMakeLists.txt M bindings/c++/CMakeLists.txt M bindings/d/CMakeLists.txt M bindings/fortran/CMakeLists.txt M bindings/lua/CMakeLists.txt M bindings/lua/lua_namespace.i.in M bindings/ocaml/CMakeLists.txt M bindings/ocaml/plcairo/CMakeLists.txt M bindings/octave/CMakeLists.txt M bindings/octave/plplot_stub.m.in M bindings/python/CMakeLists.txt M bindings/qt_gui/CMakeLists.txt M bindings/qt_gui/pyqt4/CMakeLists.txt M bindings/qt_gui/pyqt5/CMakeLists.txt M bindings/qt_gui/smoke/plplotqt.pro.in M bindings/tcl/CMakeLists.txt M bindings/tk/CMakeLists.txt M bindings/wxwidgets/CMakeLists.txt M cmake/modules/drivers-finish.cmake M cmake/modules/plplot_functions.cmake M drivers/CMakeLists.txt M drivers/tk.c M drivers/wxwidgets_dev.cpp M examples/CMakeLists.txt M examples/fortran/CMakeLists.txt M examples/lua/plplot_examples.lua.in M examples/tcl/CMakeLists.txt R051 examples/tcl/x00 examples/tcl/x00.in R056 examples/tcl/x01 examples/tcl/x01.in R051 examples/tcl/x02 examples/tcl/x02.in R052 examples/tcl/x03 examples/tcl/x03.in R051 examples/tcl/x04 examples/tcl/x04.in R051 examples/tcl/x05 examples/tcl/x05.in R051 examples/tcl/x06 examples/tcl/x06.in R051 examples/tcl/x07 examples/tcl/x07.in R051 examples/tcl/x08 examples/tcl/x08.in R051 examples/tcl/x09 examples/tcl/x09.in R051 examples/tcl/x10 examples/tcl/x10.in R051 examples/tcl/x11 examples/tcl/x11.in R051 examples/tcl/x12 examples/tcl/x12.in R051 examples/tcl/x13 examples/tcl/x13.in R057 examples/tcl/x14 examples/tcl/x14.in R051 examples/tcl/x15 examples/tcl/x15.in R062 examples/tcl/x16 examples/tcl/x16.in R051 examples/tcl/x17 examples/tcl/x17.in R069 examples/tcl/x18 examples/tcl/x18.in R051 examples/tcl/x19 examples/tcl/x19.in R051 examples/tcl/x20 examples/tcl/x20.in R051 examples/tcl/x21 examples/tcl/x21.in R051 examples/tcl/x22 examples/tcl/x22.in R051 examples/tcl/x23 examples/tcl/x23.in R069 examples/tcl/x24 examples/tcl/x24.in R051 examples/tcl/x25 examples/tcl/x25.in R069 examples/tcl/x26 examples/tcl/x26.in R051 examples/tcl/x27 examples/tcl/x27.in R051 examples/tcl/x28 examples/tcl/x28.in R051 examples/tcl/x29 examples/tcl/x29.in R051 examples/tcl/x30 examples/tcl/x30.in R054 examples/tcl/x31 examples/tcl/x31.in R069 examples/tcl/x33 examples/tcl/x33.in M examples/tk/CMakeLists.txt M fonts/CMakeLists.txt M include/plDevs.h.in M include/pldll.h.in M lib/csa/CMakeLists.txt M lib/csa/csadll.h.in M lib/nistcd/CMakeLists.txt M lib/nistcd/cddll.h.in M lib/nn/CMakeLists.txt M lib/nn/nndll.h.in M lib/qsastime/CMakeLists.txt M lib/qsastime/qsastimedll.h.in M plplot_config.h.in M plplot_test/CMakeLists.txt M plplot_test/plplot-test-interactive.sh.in M plplot_test/test_plrender.sh.in M plplot_test/test_tcl.sh.in M src/CMakeLists.txt M utils/CMakeLists.txt commit 391ec0ad0a45b4e65e631d57218bbac1be5bf54c Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Aug 1 12:46:40 2018 -0700 Octave binding and examples: permanently fix issue with non-cell arrays of character strings After the previous cellstr workaround for this issue was committed, I discovered through further hex_print experiments that the issue with conversion of non-cell arrays of character strings to C strings had nothing to do with UTF-8, but instead any string (ascii or more general UTF-8) shorter than 15 bytes always worked and any such string longer than 15 bytes always failed (i.e., generated short C strings that were either 0 length or filled with non-valid UTF-8 characters). And when I reported that issue at <https://savannah.gnu.org/bugs/index.php?54415>, I got the following extremely useful response from Markus Mützel: <quote> Recently, gcc seems to have changed the lifetime of temporary strings that are not assigned to a variable. It looks like the C++ string returned by "row_as_string" is destroyed immediately after is is created. Thus, the reference to the C string array returned by "c_str" gets invalid. The memory at that location is no longer protected from being overwritten. The results of dereferencing that pointer is undefined. You might be able to fix your code by explicitly assigning the C++ string returned by "row_as_string" to a variable for which you can control the scope. </quote> Accordingly I changed tmp_cstring = (char *) temp_matrix.row_as_string( i ).c_str(); (where the tmp_cstring declaration was properly scoped) to str = temp_matrix.row_as_string( i ); tmp_cstring = (char *) str.c_str(); (where both the str and tmp_cstring declarations were properly scoped) in our swig-generated interface and that solved all the non-cell long-string issues! (By the way, the above new style has always been used by our equivalent interface to transform cell arrays of character strings to C strings which explains why the cell array version and the previous cellstr workaround both worked.) Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot using the normal (-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON) cmake options required by Debian Buster and by building the test_noninteractive target without obvious configure, build, or run-time errors and without PostScript difference report regressions (including on-going perfect results for octave despite the current commit reverting all the cellstr workarounds in examples octave that were applied in a previous commit).  M bindings/octave/plplot_octave.i M examples/octave/x26c.m M examples/octave/x33c.m commit 95f823ec0b3ca1ed54e8a664ab9a89c8fc5c872e Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Jul 31 20:40:13 2018 -0700 Build system: bump minimum octave version we support from 3.2.0 to 3.8.0 The reason for this bump is we have no way of testing early octave versions such as 3.2. Actually, the same is likely true of 3.8.0, but I did have perfect PostScript difference reports for octave 3.8.x on my (now retired) Debian Jessie platform so on that basis I feel we can say we support 3.8.0 and above for the time being. In addition because octave-4 is now producing a perfect PostScript difference report, drop the TRY_OCTAVE4 option and the associated warnings when the user specified -DTRY_OCTAVE4=ON and simply quietly accept octave-4 if it is found. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot using the normal (-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON) cmake options required by Debian Buster and by building the test_noninteractive target without obvious configure, build, or run-time errors and without PostScript difference report regressions (including on-going perfect results for octave). M cmake/modules/octave.cmake commit d7310aa9864ce1676177f39323c9daf593ae0765 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Jul 31 13:13:11 2018 -0700 Improved workaround for Octave-4 issue with non-cell arrays of character strings Our current swig-generated octave interface uses the following method call to help determine each element of an array of pointers to C strings from an octave non-cell array of strings: tmp_cstring = (char *) temp_matrix.row_as_string( i ).c_str(); In turn this array of pointers to C strings are used as arguments to e.g., pllegend and plcolorbar. This interfacing method worked fine for octave-3, and for octave-4 it also works for most UTF-8 character strings provided by our examples, but there are some exceptions (invalid UTF-8 character strings) turned up by our examples 26 and 33 which I previously worked around before by dropping those octave examples from our test targets. Our octave binding of PLplot also provides the possibility of converting cell arrays of strings to pointers to C strings, and it turns out that method (using the cellstr function to convert from non-cell to cell array) makes examples 26 and 33 work again with octave-4. In one case, the problematic non-cell array of strings in example 26 was ["ÐмплиÑÑда"; "ФазовÑй Ñдвиг"] I have managed to replicate that issue with the simple self-contained "hex_print" project (completely independent of PLplot). However, the issue appears to be quite specific to this array of strings since other arrays caused no problems for the hex_print project. These results will be the basis of an octave-4 bug report. But in another case for page 4 of example 33, the text was ["Box Line Width 1"; "Box Line Width 2"; "Box Line Width 3"; "Box Line Width 4"; "Box Line Width 5"] , i.e., all ascii. I plan to investigate this issue further with the hex_print project, but meanwhile in this commit converting that array to cell in our example 33 avoided the invalid UTF-8 string issue. Many other cases of invalid UTF-8 string issues occurred for the plcolorbar pages (i.e., page 5 and following) of example 33. In all cases for this commit I avoided the problem by using cellstr to convert both the label and axis_opts arguments of plcolorbar to cell arrays. This commit allowed me to also add back examples 26 and 33 to our octave test case with a clean PostScript difference report for octave as a result, i.e., octave Missing examples : Differing graphical output : Missing stdout : Differing stdout : I also took this opportunity not only to add back examples 26 and 33 to our list of example pages that is maintained in cmake/modules/plplot_functions.cmake but also do further maintenance to that list, i.e., change the number of pages for example 22 from 4 to the correct number (5), and change the number of pages for example 33 from 4 (!) to the correct number (100). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot using the normal (-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON) cmake options required by Debian Buster and by building the all, test_noninteractive, and test_interactive targets without obvious configure, build, or run-time errors and with the PostScript difference report improvement noted above which reduces the PostScript difference issues down to just one which is lua Missing examples : 23 Differing graphical output : Missing stdout : Differing stdout : which is caused by my workaround (dropping example 23) for an upstream issue with lua5.3. A further test I did was to build the test_c_svg target twice followed by building the clean target. The second build of test_c_svg did not execute anything showing that the list of examples pages maintained in cmake/modules/plplot_functions.cmake did not include too much. The further build of the clean target removed all results from examples/test_examples_output_dir (except those from example 23 which necessarily must be there because example 23 is temporarily excluded from the list until the upstream Lua-5.3 issue is fixed). This result confirms the maintained list of example pages did not include too little. M bindings/octave/plplot_octave.i M cmake/modules/plplot_functions.cmake M examples/octave/x26c.m M examples/octave/x33c.m M plplot_test/test_octave.sh.in commit 94e2e5b01c3b844415244756c41e1286f9bb8935 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Jul 30 23:23:35 2018 -0700 Fix issues introduced by Phil's last two commits These issues range from the trivial (removing trailing blanks introduced into api.xml and restore correct plscmap1l as opposed to plscmap1la function name for relevant plabort calls) to important (fix introduced build errors for Tk-related source code caused by the backwards-incompatible changes [h,l,s ==> c1,c2,c3 changed member names]) to the PLControlPt struct that were introduced by Phil's commit). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot using the normal (-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON) cmake options required by Debian Buster and by building the all, test_noninteractive, and test_interactive targets without obvious configure, build, or run-time errors and without PostScript difference report regressions. M bindings/tk-x-plat/plplotter.c M bindings/tk/plframe.c M bindings/tk/plr.c M doc/docbook/src/api.xml M drivers/tk.c M src/plctrl.c commit eac0c40f5bdb8c8e574357b1d9512269ed2b9cbe Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Thu Jul 26 14:02:35 2018 +0100 Changes to documentation for plscmap1l These just update things and make the behaviour abslutely clear after the changes in the previous commit which not perform interpolation in the colorspace the user provides the coordinates in. M doc/docbook/src/api.xml commit 7ab9c0abf4bf398568c0c39aa59cabce534d17f6 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Thu Jul 26 13:39:09 2018 +0100 Changed color interpolation for plscmap1l and plscmap1la Previously scmap1l and plscmap1la took control points for interpolating a new colour map, but even if RGB coordinates were passed in, they were converted to HLS coordinates and interpolated in HLS space. The new behaviour is to interpolate in whichever space the coordinates are passed in with. M include/plplot.h M include/plstrm.h M src/plctrl.c commit 1b800ff474c2035e325471adfa1b73ecaa8e4ce9 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Jul 17 11:53:20 2018 -0700 Prefix the nistcd target The nistcd library is only built if -DPLD_cgm=ON. That option is OFF by default so this unprefixed library target was missed by our previous tests until we tried the recent prefix test with -DPLD_cgm=ON. Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot with -DPLD_cgm=ON -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON included with the usual cmake options and building the test_cgm_dyndriver target specifically and the install target in general. There were no obvious configuration, build, or install issues. M lib/nistcd/CMakeLists.txt commit 1282b2f257bd332e8f3ef21b8e40d5e66cb48c24 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Jul 16 12:06:31 2018 -0700 Change ALIAS target names of swig-generated shared objects for the Python case This commit changes the ALIAS target names from PLPLOT::plplotc and PLPLOT::Pltk_init to PLPLOT::_plplotc and PLPLOT::_Pltk_init to retain the underscore in the alias name. This result is consistent with the swig-generated names of shared objects for the Python case. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by running time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/usr/bin/cmake" --cmake_added_options "-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_interactive no --do_test_install_tree no --do_test_traditional_install_tree no --do_submit_dashboard no) where the combination of launching the script from a software tree with blank in the prefix and the above --prefix option insure blanks in source, build, and install tree prefixes are tested, the /usr/bin versions of cmake and ctest are the Debian Buster versions with version number of 3.11.2; the "-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON" are appropriate software versions of octave, Tcl/Tk/Itcl/Itk/Iwidgets, and (buggy) gnatmake that I have installed from Debian Buster; -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON tests library target names, and I have dropped the interactive tests for convenience and the install-tree components of the comprehensive tests because those don't currently work due to namespace PLPLOT:: not being implemented yet for PLplot installs. This test script completed without running into any hangs or non-zero return codes, and the accompanying test results were evaluated as follows: # Check for all errors: grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -v libGL where that last pipeline stanza is to ignore libGL error messages issued by my X-terminal box. # Check for regressions in configuration warnings: grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries' # Find each distinct run-time warning labelled by 'PLPLOT WARNING': grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u # Check for build or run-time warnings: find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out' where the trailing stanza is to remove "PLPLOT WARNING" issues, spurious gfortran warnings and cmake.out warnings. # Check for any ldd issues for the shared and nondynamic cases. # N.B. commented out this time because the above comprehensive_test.sh options # (--do_test_install_tree no --do_test_traditional_install_tree no) # preclude checking for ldd issues so there are no *.ldd.out files to # check. #grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results: grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less There are the well-known upstream issues with octave-4 and lua5.3 software that are exposed by octave examples 26 and 33, and lua example 23 which we have worked around by dropping those examples from the PostScript comparison test, but otherwise these checks of the above comprehensive test results showed no configure, build, run-time, or PostScript difference issues. Because this test was a success with the above -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON cmake option, it appears there continues to be no library target references without prefixes (PLPLOT:: for read-only targets and ${LIBRARY_TARGET_PREFIX} for writeable targets) for the CMake logic exercised by the above tests. M CMakeLists.txt M cmake/modules/plplot_functions.cmake M examples/CMakeLists.txt M examples/python/CMakeLists.txt commit 4d17d8f25cfb3df4d7e840a2ac61906ad473c5c2 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Jul 15 11:25:20 2018 -0700 Update installation of nistcd, csa, and nn headers In the nistcd case, I added the configured cddll.h header to the list of headers to be installed. In the csa and nn cases, I implemented header installation for the first time. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring the PLplot build using the cmake options -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON (consistent with modern software versions available from Debian Buster) and -DPLD_cgm=ON (needed to build and install the nistcd library), and building the install target. There were no configure, build, or install issues other than the usual gfortran "PRIVATE" and "argv_dynamic" false alarm warnings. M lib/csa/CMakeLists.txt M lib/nistcd/CMakeLists.txt M lib/nn/CMakeLists.txt commit 185b5fdcf0c0d5ad5c489b1ad7d8ede0f7b3f55f Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Jul 15 10:54:25 2018 -0700 Fix install error for configured qsastimedll.h In previous commit which introduced configuring this file, forgot to specify the ${CMAKE_CURRENT_BINARY_DIR} location of this configured file for the install command. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the install target without errors. M lib/qsastime/CMakeLists.txt commit f9142a615a427eb66fa39708a84c7ea03c45d5e9 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Jul 11 10:03:43 2018 -0700 Remove sip v4.19 deprecation warning According to <http://pyqt.sourceforge.net/Docs/sip4/directives.html#directive-%25Module> the version option for the %Module directive is deprecated and ignored for v4.19 but apparently used for prior versions of sip to help keep track of shared object API changes for other modules that might depend on our pyqt5 module. As a result prior to this commit the following deprecation warning was emitted by (Debian Buster) sip v4.19: sip: Deprecation warning: /home/software/plplot/HEAD/plplot.git/bindings/qt_gui/pyqt5/plplot_pyqt5.sip:25: %Module version numbers are deprecated and ignored Since it is unlikely we will ever have other modules depending on this one, and, in any case, this functionality is now missing from modern sip, I addressed this deprecation issue by removing the version option of our %Module directive. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the test_pyqt5_example target. The deprecation warning is now gone, and there were no obvious configure, build, or run-time issues associated with this test target. M bindings/qt_gui/pyqt5/plplot_pyqt5.sip commit dc217017dd2d276acd2a4b8cba5c74f652ec1803 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Jul 10 15:48:45 2018 -0700 Test system: Adjust what is tested by the test_interactive and test_tk targets Two steps forward, one step back.... With the Debian Buster version (5.10.1) of the Qt5 suite of libraries valgrind reports *no" memory management issues for -dev qtwidget or qt_example which is in sharp contrast with my previous results for earlier Qt5 versions. (I do see thousands of such issues when running pyqt5_example with python3 with valgrind, but python is notorious for false positives for valgrind so I discount these.) Those earlier issues were reported at <https://sourceforge.net/p/plplot/bugs/158/> so this new result is a promising indication that bug should be closed, but I am going to wait to do that until there is more of a track record for good memory management experience with Qt5 5.10.1 and above. To help gain that experience, I now allow both the test_qt_example and test_pyqt5_example targets to be dependencies of the test_interactive target for the -DPLPLOT_USE_QT5=ON case. So this change constitutes the two steps forward. I have recently discovered that the pytkdemo example intermittently hangs on exit (at least with Debian Buster Tcl/Tk versions). Therefore, I have dropped the test_pytkdemo target from the list of dependencies for both the test_interactive and test_tk targets. So this change constitutes the one step back. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by running time (nice -19 scripts/comprehensive_test.sh --cmake_command "/usr/bin/cmake" --cmake_added_options "-DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_install_tree no --do_test_traditional_install_tree no) Where the /usr/bin versions of cmake and ctest are the Debian Buster versions with version number of 3.11.2; the "-DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON" are appropriate for the Debian Buster software versions of octave and Tcl/Tk/Itcl/Itk/Iwidgets that I have installed; and I have dropped the install-tree components of the comprehensive tests because those don't currently work due to namespace PLPLOT:: not being implemented yet for PLplot installs. As a result of the above changes, this test built both the test_qt_example and test_pyqt5_example test targets but dropped the test_pytkdemo target. This test script completed without running into any hangs or non-zero return codes, and the accompanying test results were evaluated as follows: # Check for errors or any regressions in the warnings in the cmake output. grep -i error ../comprehensive_test_disposeable/*/*/output_tree/cmake.out grep -i warning ../comprehensive_test_disposeable/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target |requires shared libraries' |less # Find number of distinct run-time warnings labelled by 'PLPLOT WARNING': grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u # Check for build or run-time warnings: ls ../comprehensive_test_disposeable/*/*/output_tree/* |grep -v cmake.out |xargs grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic' where I have ignored the previously covered 'PLPLOT WARNING' issues and ignored the spurious gfortran warnings. # Check for all errors: grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out |grep -v libGL where that last pipeline stanza is to ignore libGL error messages issued by my X-terminal box. # Check for any ldd issues for the shared and nondynamic cases. # N.B. commented out because the above comprehensive_test.sh options # (--do_test_install_tree no --do_test_traditional_install_tree no) # preclude checking for ldd issues so there are no *.ldd.out files to # check. grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable/*/*/output_tree/*ldd.out # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results. grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less There were run-time deprecation warnings for pyqt5 found with the above checks which I will investigate later, and there are the well-known upstream issues with octave-4 and lua5.3 software that are exposed by octave examples 26 and 33, and lua example 23 which we have worked around by dropping those examples from the PostScript comparison test, but otherwise these checks of the above comprehensive test results showed no configure, build, run-time, or PostScript difference issues. M examples/CMakeLists.txt commit 6e36da7fb40f8d867d11dd78fde5fa2b104c1c8d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Jul 9 15:35:39 2018 -0700 Reduce warning messages for the test_noninteractive target The changes were as follows: * For the Fortran binding, drop declarations of some unused variables. * For the Fortran examples, don't define an unused function. * For the OCaml examples, drop some unneeded calculations. * For the higher-level Octave binding that is implemented with Octave functions, replace calls to the deprecated (in Octave 4.4) toascii function with calls to the recommended replacement (the double function). I assume this replacement is backwards compatible since I have discovered with web searchs that the double function has been documented back to octave-2.9 and likely even earlier. However, I have no means to test octave versions less than 4.4. I speculate that toascii was deprecated in Octave 4.4 because its name was a horrible misnomer describing the reverse of what occurs which is conversion of each character in a string to the corresponding integer, but by default integers are internally stored in octave as double-precision floating point numbers so the actual conversion was from each character in the string to double (which I assume is why double is the recommended replacement). As a result of these changes the only warning messages left that are emitted by the test_noninteractive target are run-time "PLPLOT WARNING" messages that have been present for a long time, and the following spurious warnings emitted by gfortran: 1. argv_dynamic warning message. /home/software/plplot/HEAD/plplot.git/examples/fortran/x01f.f90:51:0: character(len=:), dimension(:), allocatable :: argv_dynamic Warning: â.argv_dynamicâ is used uninitialized in this function [-Wuninitialized] I am not sure where the "." part of ".argv_dynamic" comes from in that warning message. In any case, I am virtually positive this warning is spurious since argv_dynamic is an output argument of the routine plget_arguments(argv_dynamic) which is the first mention of argv_dynamic in an executable statement in this routine. 2. Spurious "PRIVATE" warning messages. There are 56 of these due to a long-standing gfortran bug (see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111> and <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861>). A typical example is /home/software/plplot/HEAD/plplot.git/bindings/fortran/plplot_small_modules.f90:108:8: function interface_strlen(s) bind(c, name='strlen') 1 Warning: Symbol âinterface_strlenâ at (1) is marked PRIVATE but has been given the binding label âstrlenâ Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot with the cmake options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and building the test_noninteractive target with octave 4.4. All but the "PLPLOT WARNING" and spurious fortran warning messages mentioned above are now gone. This overall test showed no obvious configure, build, run-time, or PostScript difference report regressions as a result of this commit. M bindings/fortran/plplot_small_modules.f90 M bindings/octave/PLplot/ginput.m M bindings/octave/PLplot/support/__pl_matstr.m M examples/fortran/x15f.f90 M examples/ocaml/x19.ml commit a4bada0048d93cc79900807b576a52e1503695a0 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Jul 9 11:26:00 2018 -0700 Testing system: Fix long-standing name clash between various "test.error" files output by test scripts My thanks to Nils Gladitz for going above and beyond by investigating this PLplot bug and drawing my attention to the test.error files in response to my question on the CMake mailing list. These name clashes create obvious race conditions for parallel builds of test targets. For example, after the fix was applied here is the list of the various "*test.error" files generated by the test_noninteractive target: software@merlin> find . -name "*test.error" ./examples/octave_psc_test.error ./examples/c_pngcairo_test.error ./examples/c_pdfqt_test.error ./examples/c_jpgqt_test.error ./examples/c_svgcairo_test.error ./examples/c_svg_test.error ./examples/tcl/tcl_psc_test.error ./examples/c_pscairo_test.error ./examples/c_psttf_test.error ./examples/c_ps_test.error ./examples/c_pngqt_test.error ./examples/c_svgqt_test.error ./examples/lua/lua_psc_test.error ./examples/cxx_psc_test.error ./examples/ada_psc_test.error ./examples/d_psc_test.error ./examples/c_tiffqt_test.error ./examples/ocaml_psc_test.error ./examples/c_psttfc_test.error ./examples/c_epscairo_test.error ./examples/c_ppmqt_test.error ./examples/c_pdfcairo_test.error ./examples/fortran_psc_test.error ./examples/python_psc_test.error ./examples/c_bmpqt_test.error ./examples/c_psc_test.error ./examples/c_xfig_test.error ./examples/java_psc_test.error Those versions of the files that are located in the examples directory obviously could have interfered with each other before the name clash was resolved. I don't understand the exact mechanism, but it turns out those races caused a long-standing problem of groups of extra ascii nul characters ('\0') to appear in the output of parallel builds, and I am pleased that race condition symptom is now gone as a result of this commit. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the test_noninteractive target using make -j16 test_noninteractive >& test_noninteractive.out The command od -c test_noninteractive.out |grep '\\0' showed those results were free of embedded '\0' (ascii nul) characters that were there for parallel builds before the current commit. This overall test showed no obvious configure, build, run-time, or PostScript difference report regressions as a result of this commit. M plplot_test/plplot-test-interactive.sh.in M plplot_test/test_ada.sh.in M plplot_test/test_c.sh.in M plplot_test/test_c_interactive.sh.in M plplot_test/test_cxx.sh.in M plplot_test/test_d.sh.in M plplot_test/test_fortran.sh.in M plplot_test/test_java.sh.in M plplot_test/test_lua.sh.in M plplot_test/test_ocaml.sh.in M plplot_test/test_octave.sh.in M plplot_test/test_octave_interactive.sh.in M plplot_test/test_plrender.sh.in M plplot_test/test_python.sh.in M plplot_test/test_tcl.sh.in commit 179809cb9eecb3e75997ca7aa39d6e1cb39d8708 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Jul 7 23:53:17 2018 -0700 Octave binding: remove last build warning The build warning was caused by the following code fragment propagated to the C++ code generated by swig to implement the octave binding: // Check if version >= 3.4.0 #if OCTAVE_API_VERSION_NUMBER < 45 retval( 0 ) = octave_value( local_charMatrix, true ); #else retval( 0 ) = octave_value( local_charMatrix ); #endif This is an attempt to use the first (ancient) octave_value form if the user has a very old version of octave, but this is inconsistent with other parts of the code which uses the modern (second) form of octave_value without attempting to support ancient octave. Furthermore, even this attempt at backwards incompatibility with ancient octave is not implemented correctly since OCTAVE_API_VERSION_NUMBER is not #defined for modern octave so the C++ preprocessor assumes its value is 0, and the first (ancient) form of the octave_value call is (incorrectly) used with accompanying build warnings. I have absolutely no idea how that ancient form still worked for octave-4.4 prior to this commit, but in any case the warning issue is solved by this commit by only using the second modern form of the octave_value call consistent with other code in plplot_octave.i. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot with the cmake options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and building the test_noninteractive target with octave 4.4. All remaining deprecation build warnings for octave are now gone, and this test showed no obvious configure, build, or run-time regressions as a result of this commit. M bindings/octave/plplot_octave.i commit b940cde452cbb8bea541087f66696137c4f6bbee Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Jul 7 14:34:17 2018 -0700 Update styling script to handle swig %# preprocessor directives Some swig configuration files (e.g., bindings/octave/plplot_octave.i) use the swig "%#" preprocessor directive which tells swig to pass that directive through to the C or C++ preprocessor rather than using the swig preprocessor to process that directive. Thus, from a style perspective, swig "%#" preprocessor directives should be treated the same way by uncrustify as the normal C or C++ "#" preprocessor directive. So this commit implements that by the appropriate sed magic to replace "%#" by "#" before uncrustify processes the file and then replace "#" by "%#" (for appropriately commented lines) after uncrustify processes the file to restore back to appropriate swig configuration script form. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by running the new version of scripts/style_source.sh that is committed in this commit. This version of the style script was used to style bindings/octave/plplot_octave.i with good indentation before that file was committed in the last commit, and running this version of the style script now shows (as expected) no further style changes to bindings/octave/plplot_octave.i (or any other file) are necessary. M scripts/style_source.sh commit 76f486baadf33014ec97d03772bc591d22ae2231 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Jul 7 14:29:00 2018 -0700 Octave binding: For octave-4.4 and above to avoid deprecations warnings replace calls to the is_empty and is_cell methods by calls to the preferred octave-4.4 names for those methods which are isempty and iscell As of version 4.4, the preferred names for the is_empty and is_cell methods have been changed to isempty and iscell to make them consistent with the corresponding octave function names. The current commit uses conditional compilation to use isempty and iscell for octave-4.4 (to avoid the 4.4 is_empty and is_cell deprecation warnings), but otherwise it continues to use the old names. Therefore, this commit should not introduce issues for octave-4 versions below 4.4 and likely also octave-3, but I am not in a position to test those older octave versions. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot with the cmake options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and building the test_noninteractive target with octave 4.4. All the previous is_empty and is_cell deprecation build warnings are now gone, and this test showed no obvious configure, build, or run-time regressions as a result of this commit. M bindings/octave/plplot_octave.i commit d96ac4b469f2e5028ff2fa773fce53ccf2d5d1a7 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Jul 6 14:48:17 2018 -0700 Octave binding: For octave-4.4 and above replace calls to feval by calls to octave::feval to avoid a deprecation warning As of version 4.4, feval is deprecated in favour of octave::feval. The current commit uses conditional compilation to use octave::feval for octave-4.4 (to avoid the 4.4 feval deprecation warning), but otherwise it continues to use feval. Therefore, this commit should not introduce issues for octave-4 versions below 4.4 and likely also octave-3, but I am not in a position to test those older octave versions. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot with the cmake options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and building the test_noninteractive target with octave 4.4. All the previous feval-related deprecation build warnings were gone, and this test showed no obvious configure, build, or run-time regressions as a result of this commit. M bindings/octave/plplot_octave.i commit 844e7f3454b272ad3b4b83413e36e4c7ede6a68a Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Jul 6 11:29:19 2018 -0700 Solve dereferencing bug for pltcl application This bug was introduced by commit c1d5dba8d1 which made (in 2010) the following change to pltcl.c diff --git a/utils/pltcl.c b/utils/pltcl.c index 72a0055b4..1b15f5f93 100644 --- a/utils/pltcl.c +++ b/utils/pltcl.c @@ -68,10 +68,13 @@ main( int argc, const char **argv ) static int plExitCmd( ClientData clientData, Tcl_Interp *interp, int argc, char **argv ) { + char *tmp; + // Print error message if one given - if ( interp->result != NULL && interp->result[0] != '\0' ) - fprintf( stderr, "%s\n", interp->result ); + tmp=Tcl_GetStringResult(interp); + if ( tmp != NULL && tmp != '\0' ) + fprintf( stderr, "%s\n", Tcl_GetStringResult(interp)); plspause( 0 ); plend(); The problem with that change was the second use of tmp in the if statement was not derefenced (to check that the size of the error message string was non-zero). This issue was discovered by gcc 7.3.0 which emitted the following warning message before this fix: bindings/tcl/pltcl.c:74:29: warning: comparison between pointer and zero character constant [-Wpointer-compare] if ( tmp != NULL && tmp != '\0' ) ^ Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the test_pltcl_standard_examples target. The current fix removed the above build warning, and there were no obvious run-time issues with the results of this test. M bindings/tcl/pltcl.c commit 5eced65fc75113200adb273f868bcd0d4fdb54c8 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Jul 4 16:30:19 2018 -0700 Build system: Fix OCTAVE_PREFIX (and derived OCTAVE_M_DIR) configuration bug for the octave-4.4 case For octave-4.4 __octave_config_info__("prefix") has stopped working, and the similar octave-config --print PREFIX command generates an empty string. Experimentally, I have discovered that although __octave_config_info__("octave_home") does not work octave-config --print OCTAVE_HOME does generate the appropriate "/usr" string representing the install prefix for octave. Therefore, I have replaced all instances of using the __octave_config_info__ octave function with the equivalent octave-config command, and solved the OCTAVE_PREFIX issue for octave-4.4 by searching first for PREFIX, and if that generates an empty string, search for OCTAVE_HOME instead. This fix also solved the (derived) OCTAVE_M_DIR issue where that variable had the wrong install prefix. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot with cmake and demonstrating via those results that OCTAVE_PREFIX and the derived OCTAVE_M_DIR are now defined properly again for octave-4.4. As far as I know, this fix has been made in a backwards-compatible way, i.e., it should work for octave-3, but I am not in position to test that. M cmake/modules/octave.cmake commit 4e36c1d0e2e6f31af678a3d7fc27cf0f0b0ce793 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Jul 4 13:19:28 2018 -0700 Build system: Fix lua and octave rebuild bugs A maintenance quirk for the PLplot build system is that when examples are (temporarily) dropped (as in previous lua and octave commits to avoid exposing lua and octave upstream bugs, GRR) it is necessary to drop those examples from the list_example_files function in cmake/modules/plplot_functions.cmake to avoid rebuild bugs such as the ones fixed by this current commit. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the test_diff_psc target twice and demonstrating for the second of those that there are no unnecessary rebuilds such as occurred for lua and octave examples prior to this commit. M cmake/modules/plplot_functions.cmake commit ade600099f51564eef1a80acebac94dd90623069 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Jul 4 11:41:40 2018 -0700 Style previous commits M bindings/octave/plplot_octave.i M lib/csa/csa.c commit 7bc62a898d483b92c4a122bb057649ad1bdf6b32 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Jul 4 11:09:15 2018 -0700 Build system: fix "cmake -E copy_if_different" re-copy bugs The problem with using "cmake -E copy_if_different" within custom commands and targets is the date does not get updated when the file is the same (e.g., when the source file for the copy is touched explicitly or implicitly via git workflow). This means the "cmake -E copy_if_different" command and *all* target dependencies of that command get incorrectly re-run until you start fresh from an empty build tree. This commit solves these bugs by replacing "cmake -E copy_if_different" for all cases where it occurs in a custom command or target with "cmake -E copy" since the latter command always updates the timestamp of the destination file which effectively eliminates further re-copies. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by rebuilding the octave_examples and lua_examples targets for a case where certain of the octave and lua examples had been touched by git workflow). The result was the touched source files were updated in the build tree once, and then after that the timestamps on those updated files kept the command from incorrectly being re-run. N.B. there are other lua and octave incorrect re-run issues exposed by running the test_diff_psc target twice. Those issues still require further investigation, but this commit, at least, eliminates the re-copy issue that was obfuscating the test_diff_psc target issue. M bindings/ada/CMakeLists.txt M bindings/ocaml/CMakeLists.txt M bindings/ocaml/plcairo/CMakeLists.txt M bindings/tcl/CMakeLists.txt M examples/lua/CMakeLists.txt M examples/ocaml/CMakeLists.txt M examples/python/CMakeLists.txt M examples/tcl/CMakeLists.txt M examples/tk/CMakeLists.txt M plplot_test/CMakeLists.txt M www/announce/CMakeLists.txt commit 014bbe28f756c55f02b8152b0e7d10c185da489f Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Jul 3 16:17:09 2018 -0700 octave binding and examples; adjust for octave-4 changed interpretation of strings The octave-4 difference we are adjusting for is that NULL's embedded in strings no longer terminate output of printf, etc. Instead, the entire string is output with embedded NULL's ignored. To adjust for this change, the octave binding of plplot stores the results from plgver, plgdev, and plgfnam (all the PLplot API with output character string arguments) in an ordinary C string, and inserts the NULL-terminated substring of those results into an octave charMatrix which is then returned to the octave environment as an octave string of the correct (NULL-terminated) length. N.B. Backwards-incompatible change to plgver, plgdev, and plgfnam. The results for these functions are backwards incompatible because the result returned to the octave environment is a string rather than the transpose of a string which was the previous (badly designed) historical result. Also note because of bad historical choices there are many other data returned by the current octave binding for PLplot where the transpose must be taken and the long-term plan is to introduce more backwards-incompatible changes by getting rid of all these unnecessary transposes. So this commit is the first step toward that goal. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring PLplot with cmake 3.11.2 using the options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and building the test_diff_psc target. The configuration, build, and run time results had no obvious errors, and the present commit solved stdout differences for the octave part of the PostScript difference report. Therefore, the exceptions to a perfect PostScript difference report are now reduced to octave Missing examples : 26 33 Differing graphical output : Missing stdout : Differing stdout : lua Missing examples : 23 Differing graphical output : Missing stdout : Differing stdout : where those missing examples are a temporary workaround to avoid exposing upstream bugs in octave 4 (likely 8-bit clean issues with octave-4 UTF-8 handling of strings) and lua5.3 (see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for details of this severe bug). M bindings/octave/INSTALL M bindings/octave/PLplot/figure.m M bindings/octave/plplot_octave.i M examples/octave/x01c.m M examples/octave/x14c.m commit 0b14d2a56623e88a4cf5431d36b0c1ac187628a2 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Jun 23 14:56:10 2018 -0700 Adjust Lua examples so they give correct results for Lua5.3 All these issues are caused by Lua5.3 implementing default formatting of the conversion of numbers to strings that is different than prior versions. So in each case the example correction was to replace default formatting with definite formatting when converting numbers to strings. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by building the test_diff_psc target. The previous lua component of the report was lua Missing examples : Differing graphical output : 14a 19 23 Missing stdout : Differing stdout : 31 This and the prior commit substantially improved this result to lua Missing examples : 23 Differing graphical output : Missing stdout : Differing stdout : where the remaining issue (example 23 missing from lua testing) is by design to avoid exposing an upstream bug with lua5.3. (See the previous commit message for more details about this issue.) M examples/lua/x14.lua M examples/lua/x19.lua M examples/lua/x31.lua commit 61be11becdc4577a01ffe3c1dde207530deed92e Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Jun 23 14:50:45 2018 -0700 Drop lua example 23 from tests to avoid upstream lua5.3 bug The upstream bug is a severe one, see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for details. Therefore, all we can do on the PLplot side of things is to avoid exposing this bug by not running lua example 23 in our tests. M plplot_test/test_lua.sh.in commit 9893349d1408545275d4f4187d4b7ba745a3c3db Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Jun 20 14:36:36 2018 -0700 Build system: Force DROP_GTK_PLUS_2_BUILDS to be ON The fundamental purpose of this change is to make sure all our GTK+ dependencies are version 3 rather than version 2 since version 3 has long been the standard version of GTK+ and a combination of versions 2 and 3 will likely not work in any case. The practical implication of this change is examples/c/extXdrawable_demo.c is never built since that app consists of calls to GTK+ API that was already deprecated in GTK+ version 2 and completely removed in GTK+ version 3. In addition, this change means the PLplot ocaml "cairo" API cannot be used, but that API has already been disabled due to lack of maintenance. M cmake/modules/plplot.cmake commit 99472347145a5faa94411ed81f10ed028f2411cf Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Jun 9 13:09:40 2018 -0700 First collection of changes to make PLplot support modern versions (as available from Debian Buster) of free software These changes are as follows: * Support Lua version 5.3 (and likely versions back to 5.2). Along with updates to cmake/modules/lua.cmake, this change required updating the cmake/modules/FindLua.cmake to be consistent with the CMake version 3.8.0 official version of this find module. The following minor change was required to make this find module work as part of the PLplot build system: ______________________________ software@merlin> diff -au Modules/FindLua.cmake ~/plplot/HEAD/plplot.git/cmake/modules/ --- Modules/FindLua.cmake 2018-06-09 10:41:24.374851079 -0700 +++ /home/software/plplot/HEAD/plplot.git/cmake/modules/FindLua.cmake 2018-05-20 14:51:32.760113838 -0700 @@ -187,7 +187,8 @@ endif () endif () -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) +#include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) +include(FindPackageHandleStandardArgs) # handle the QUIETLY and REQUIRED arguments and set LUA_FOUND to TRUE if # all listed variables are TRUE FIND_PACKAGE_HANDLE_STANDARD_ARGS(Lua ______________________________ The plan is to drop this find module from PLplot and use the official version from then on once our minimum version of CMake is 3.8.0 or higher. * Support gdc version 7 (and likely version 6 and possibly 5). The principal change here is to adjust for a rename of libgphobos2 (required by gdc version 4) ==> libgphobos. The libgphobos2 name was used for Debian Jessie gdc 4.9.2 and was changed to the libgphobos name somewhere between that version and gdc version 6. Note this entire set of gdc-related changes was so simple it is likely we do support gdc-6 and we might even support gdc-5 if that version uses the new libgphobos name, but I am not in position to test either gdc-6 or gdc-5. * Support octave version 4.2.2 (and likely prior 4.x versions as well as octave 3.8.2 that was so well-tested on Debian Jessie). The principal change here is to use __octave_config_info__ if available with a fallback to octave_config_info (deprecated for 4.2.2 in favour of __octave_config_info__) to quiet deprecation messages. In addition, I temporarily dropped octave standard examples 26 and 33 (two of our 4 UTF-8 examples) because they appear to expose eight-bit clean issues for octave 4.2.2 that mess up UTF-8 strings in PLplot arguments some of the time. This issue needs further study, but will likely need to be addressed upstream by the octave developers. * Work around what appears to be an issue with gcc version 7.3.0-21 from Debian Buster where the explicit (or implicit via -O3) use of the -finline-functions gcc option causes segfaults in the libcsirocsa library. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Buster) by configuring the PLplot build using the cmake (version 3.11.2 from Buster) options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON, and within the build tree for the shared library case, building the test_noninteractive and all targets, and running ctest. There was one minor configuration regression compared to Debian Jessie results, i.e., -- Determine compile and link flags for extXdrawable_demo -- Checking for module 'gtk+-x11-2.0' -- No package 'gtk+-x11-2.0' found -- WARNING: gtk+-x11-2.0 not found. extXdrawable_demo not built. The solution is to update extXdrawable_demo so it works with GTK+ version 3. There was also no obvious build or run-time errors for these tests. However, the following PostScript regressions were introduced compared to the Jessie results: [...] octave Missing examples : 26 33 Differing graphical output : Missing stdout : Differing stdout : 01 14 [...] lua Missing examples : Differing graphical output : 14a 19 23 Missing stdout : Differing stdout : 31 The missing octave examples were necessary because of the (likely) upstream octave 4.x regressions with 8-bit clean handling of UTF-8 strings compared to octave-3.8.2. The remaining PostScript regressions relative to Debian Jessie need further study but will likely be solved by adjusting the relevant examples so they work properly on octave-4 and Lua-5.3. M cmake/modules/FindLua.cmake M cmake/modules/language_support/cmake/CMakeDInformation.cmake M cmake/modules/language_support/cmake/CMakeDetermineDCompiler.cmake M cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake M cmake/modules/lua.cmake M cmake/modules/octave.cmake M lib/csa/CMakeLists.txt M lib/csa/csa.c M plplot_test/test_octave.sh.in commit f580dd5c22f070d44362a777ddb2256f8857f27d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Apr 15 13:25:40 2018 -0700 Build system: Fix -DTEST_DYNDRIVERS=ON case when -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON My previous tests of -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON found issues with (the default) -DTEST_DYNDRIVERS=ON case which are fixed in this commit. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by running time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON" --build_command "make -j4 -k" --do_test_install_tree no --do_test_traditional_install_tree no --do_submit_dashboard no) (Note because this command was run from a "spaced" source tree and the above "spaced" --prefix, this test has a space in the prefixes of the source, build, and install trees.) Check the results: # Check for any regressions in the warnings in the cmake output. less ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out # Check for some non-standard warnings: grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vEi 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout|unused|uninitialized' # Check for all errors: grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out # Check for any ldd issues for the shared and nondynamic cases. # N.B. commented out because the above comprehensive_test.sh options preclude # checking for ldd issues so there are no *.ldd.out files to check. #grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results. grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less These checks showed no configure, build, run-time, or PostScript difference issues with the above comprehensive test (limited to just the build-tree case because of the -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON side effect that would cause errors for the install-tree case). I additionally checked the -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=OFF case by building from a fresh start the test_diff_psc target for both the (default) -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=OFF case as well as the -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON case that is redundant with one part of the above comprehensive test. All was well for the OFF case, but I got Ada build errors for the ON case that disappeared again when I ran that test for the second time (from an identical clean start in both cases). So I am still encountering intermittent Ada build errors (in this case for the first -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON case above, but not for any of the other cases) even though my extensive testing of my hardware indicates no issues. Currently, I think the most likely explanation of these intermittent errors is and Ada build tool bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451> whose fix is not present in the ancient (4.9.2) version of Ada build tools I have access to at the moment. (See further discussion on the PLplot devel list). Therefore, from these good comprehensive and test_diff_psc target results (if you exclude the case where intermittent Ada build issues showed up for the test_diff_psc target) it appears all non-prefixed writeable library target references in our build system have been eliminated (at least for the CMake logic exercised by the above tests). M drivers/CMakeLists.txt M drivers/test-drv-info.c commit 0df4e30e6b469edac0ae6cea8c32250201f8341f Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Apr 6 14:58:02 2018 -0700 Build system: Implement TEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS experimental option This new option defaults to OFF (which unsets the CMake variable LIBRARY_TARGET_PREFIX), but when this option is ON the CMake variable LIBRARY_TARGET_PREFIX is set to "temporary_target_". This commit also changes all writeable library targets in the build system (and also as an unwanted side effect [see below] that limits what we can test when -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON the corresponding dll or library filename) to have a prefix of ${LIBRARY_TARGET_PREFIX}. So as a result of this commit and a prior commit that prefixed all read-only library targets with "PLPLOT:::, all library targets in our core build system that we use for the build tree should have a prefix of either ${LIBRARY_TARGET_PREFIX} or "PLPLOT::". Therefore when -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON any exercised CMake code that refers to an unprefixed library target such as "plplot" will error out with an unknown target message at cmake time or some other error message at run time. Of course, CMake code paths not followed can still refer to unprefixed library targets so it is useful to use -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON for as wide variety of configuration, build, and test conditions as provided by scripts/comprehensive_test.sh to test as much of CMake logic in the build-tree build system as possible. However, note that such tests must be limited just to build-tree tests since the side effects mentioned above completely screw up both the CMake-based and traditional install-tree build systems. Furthermore, I have not yet figured out how to make this all work for the (default) -DTEST_DYNDRIVERS=ON case so my tests below used -DTEST_DYNDRIVERS=OFF. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by running (from a source tree with a space in the prefix) time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DTEST_DYNDRIVERS=OFF -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON" --build_command "make -j4 -k" --do_test_install_tree no --do_test_traditional_install_tree no) (Note because of the choice of a "spaced" source tree and the above --prefix, this test has a space in the prefixes of the source, build, and install trees.) Check the results: # Check for any regressions in the warnings in the cmake output. less ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out # Check for some non-standard warnings: grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout' # Check for all errors: grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out # Check for any ldd issues for the shared and nondynamic cases. grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results. grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less These checks showed intermittent failures for certain parts (xtraditional28a, xtraditional33a) of the Ada part of the build with two separate complaints about various files written by the gnat compiler. At this stage I cannot figure out the source of this issue since it comes and goes and is hard to reproduce. But at one point I got through the entire test above without Ada failures, and found an obvious issue with the static OCaml binding library which I fixed and which has absolutely nothing to do with Ada. I then tried the test above again, which failed for the nondynamic case for the build of one of the Ada examples. I then followed up by a specific static build of the ocaml binding library that exercised the fixed build-system CMake code for that case, and all was well. Therefore, I think from these piecemeal results that all is well with the current commit, but further testing needs to be done as above once I figure out the source of the intermittent Ada build errors. N.B. I have run git fsck --strict --no-dangling before this commit. That result showed the git filesystem had no inconsistencies. Normally (from past experience with a slowly failing disk), there are such inconsistencies whenever the disk is experiencing some bad block issues. So the good result for this command is encouraging with regard to the health of my computer hardware. But "just in case", I plan to run the same git fsck command just before the push of this commit and will only do that push if the fsck is again a success. M CMakeLists.txt M bindings/ada/CMakeLists.txt M bindings/c++/CMakeLists.txt M bindings/d/CMakeLists.txt M bindings/fortran/CMakeLists.txt M bindings/java/CMakeLists.txt M bindings/lua/CMakeLists.txt A bindings/lua/lua_namespace.i.in M bindings/lua/plplotluac.i M bindings/ocaml/CMakeLists.txt M bindings/ocaml/plcairo/CMakeLists.txt M bindings/octave/CMakeLists.txt R075 bindings/octave/plplot_stub_hand_crafted.m bindings/octave/plplot_stub.m.in M bindings/python/CMakeLists.txt M bindings/qt_gui/CMakeLists.txt M bindings/qt_gui/pyqt4/CMakeLists.txt M bindings/qt_gui/pyqt5/CMakeLists.txt M bindings/qt_gui/smoke/CMakeLists.txt M bindings/qt_gui/smoke/plplotqt.pro.in M bindings/tcl/CMakeLists.txt M bindings/tk-x-plat/CMakeLists.txt M bindings/tk/CMakeLists.txt M bindings/wxwidgets/CMakeLists.txt M cmake/modules/cgm.cmake M cmake/modules/drivers-finish.cmake M cmake/modules/plplot_functions.cmake M cmake/modules/qt.cmake M cmake/modules/tk.cmake M doc/docbook/src/CMakeLists.txt M drivers/CMakeLists.txt M examples/CMakeLists.txt M examples/ada/CMakeLists.txt M examples/c++/CMakeLists.txt M examples/c/CMakeLists.txt M examples/d/CMakeLists.txt M examples/fortran/CMakeLists.txt M examples/lua/CMakeLists.txt M examples/lua/plplot_examples.lua.in M examples/octave/CMakeLists.txt M examples/python/CMakeLists.txt M examples/python/pyqt4_example.py M examples/python/pyqt5_example.py M examples/tcl/CMakeLists.txt M examples/tk/CMakeLists.txt M fonts/CMakeLists.txt M include/pldll.h.in M lib/csa/CMakeLists.txt R096 lib/csa/csadll.h lib/csa/csadll.h.in M lib/nistcd/CMakeLists.txt R096 lib/nistcd/cddll.h lib/nistcd/cddll.h.in M lib/nn/CMakeLists.txt R096 lib/nn/nndll.h lib/nn/nndll.h.in M lib/qsastime/CMakeLists.txt R096 lib/qsastime/qsastimedll.h lib/qsastime/qsastimedll.h.in M src/CMakeLists.txt M utils/CMakeLists.txt commit 9cc1d067ee7fd7213d17ac1d737515828cad4d19 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Mar 23 17:15:46 2018 -0700 Build system: configure a more uniform build of modules, swig-generated modules, static libraries and shared libraries I implemented this change using the new configure_library_build function that replaces the previously used (and misnamed) build_library function. This new CMake function has a different set of arguments then the removed build_library function. This new function allows not only the configuration of new explicit STATIC and SHARED builds or the old implied (via BUILD_SHARED_LIBS) STATIC or SHARED builds, but also the explicit new configuration of MODULE (dll) and swig-generated MODULE builds. The type of library (i.e., "" [if decided by BUILD_SHARED_LIBS], "MODULE", "STATIC", "SHARED", or a language such as "python" [if a swig-generated module]) is now specified as the second argument. In addition the old trailing namespace argument is dropped in favour of an external variable LIBRARY_NAMESPACE that should be set (with a trailing "::") globally once for a given project, e.g., set(LIBRARY_NAMESPACE "PLPLOT::") for the PLplot project. As a result of this current commit, the "add_library" string only appears in the following files in the PLplot source tree: software@raven> find . -type f |grep -v .git |xargs grep -il 'add_library' ./ChangeLog.release ./cmake/test_ada/src_lib/CMakeLists.txt ./cmake/modules/UseSWIG.cmake ./cmake/modules/plplot_functions.cmake ./cmake/epa_build/libagg/libagg_CMakeLists.txt ./cmake/epa_build/libqhull/src/CMakeLists.txt ./cmake/epa_build/libharu/cmake.patch ./cmake/epa_build/shapelib/shapelib_CMakeLists.txt ./cmake/test_fortran/src_lib/CMakeLists.txt That is, if you look just at the PLplot project (i.e., you exclude historical mentions [ChangeLog.release] and various epa_build and test mini-projects), the actual use of the add_library command is reduced to the UseSWIG.cmake module copied from the CMake project and the configure_library_build function in plplot_functions.cmake. In other words the configuration of the builds of shared objects now proceeds in a uniform manner for PLplot that is controlled by the logic in the configure_library_build function, and any idiosyncratic target property adjustments that might be done after the call to configure_library_build for each CMake "library" (actually a library or a dll) built by PLplot. Additional cleanups and changes: * For the swig-generated MODULE's, I now use ${SWIG_MODULE_${swig_target_name}_wrap_REAL_NAME}, e.g., ${SWIG_MODULE_plplotc_wrap_REAL_NAME} to refer to the real target name after configure_build_library is called. This automatically takes care of issues such as the "_" prefix used for the actual _plplotc target that is used when configuring swig-generated Python builds. * For the swig-generated MODULE's, I now have dropped all PREFIX and SUFFIX overwrites on the module properties. Instead, I now rely on UseSWIG.cmake to set these properties correctly for each given Swig language. And it appears that is currently done consistent with our previous overwrites. However, if there is some PREFIX or SUFFIX screwup in UseSWIG.cmake for any Swig language or platform, I will adjust that file accordingly and report the issue to CMake as a CMake bug. * Had to set smokeplplotqt_SOVERSION and smokeplplotqt_VERSION in cmake/modules/plplot_versions.cmake so the smokeplplotqt library build could be configured in the standard way using configure_library_build. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by configuring PLplot with the -DENABLE_smoke=ON -DBUILD_HERSHEY_FONTS=ON options (to allow testing the build of the smokeplplotqt and hershey libraries) and by building the following targets: * smokeplplotqt There were no configure or build issues and ldd -r showed no run-time loader or symbol issues with this library (currently only used externally by one of Hazen Babcock's projects, but it would be good to implement at least a simple run-time test of this library as part of PLplot). * generate_stndfonts and generate_xtndfonts These targets build executables which link to the static hershey library, and I tested these executables as follows: ldd -r fonts/generate_stndfonts ldd -r fonts/generate_xtndfonts fonts/generate_stndfonts diff plstnd5.fnt ../plplot.git/data/ fonts/generate_xtndfonts diff plxtnd5.fnt ../plplot.git/data/ The diffs showed no changes compared to the source-tree versions of these generated Hershey font files. * test_noninteractive There were no configuration, build, run-time, or Postscript differences with this target. * test_interactive There were no configuration, build, or run-time issues with this target. N.B. the above good test_noninteractive and test_interactive tests are not comprehensive. For example, the present changes have just been tested in the build tree and just for the shared libraries/dynamic devices case to save time. So planned future comprehensive tests that do test many more configuration possibilities for both build-tree and install-tree may turn up additional issues for the present intrusive commit. M CMakeLists.txt M bindings/ada/CMakeLists.txt M bindings/c++/CMakeLists.txt M bindings/d/CMakeLists.txt M bindings/fortran/CMakeLists.txt M bindings/java/CMakeLists.txt M bindings/lua/CMakeLists.txt M bindings/ocaml/CMakeLists.txt M bindings/ocaml/plcairo/CMakeLists.txt M bindings/octave/CMakeLists.txt M bindings/python/CMakeLists.txt M bindings/qt_gui/CMakeLists.txt M bindings/qt_gui/pyqt4/CMakeLists.txt M bindings/qt_gui/pyqt5/CMakeLists.txt M bindings/qt_gui/smoke/CMakeLists.txt M bindings/tcl/CMakeLists.txt M bindings/wxwidgets/CMakeLists.txt M cmake/modules/plplot_functions.cmake M cmake/modules/plplot_version.cmake M drivers/CMakeLists.txt M examples/fortran/CMakeLists.txt M fonts/CMakeLists.txt M lib/csa/CMakeLists.txt M lib/nistcd/CMakeLists.txt M lib/nn/CMakeLists.txt M lib/qsastime/CMakeLists.txt M src/CMakeLists.txt commit f4d7e1a30ec3a8e071574865d7780fce8d411fbd Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Mar 16 19:21:05 2018 -0700 Python binding: Improve UTF-8 fixup Our swig documentation strings (which include some UTF-8 glyphs such as "â¥") are propagated directly to the swig-generated bindings/python/plplotc.py Python script. So years ago when our bindings were strictly Python2 we had to implement a sed fixup to modify that file to append " It uses coding: utf-8" to the first line of that file to signal (according to PEP 263) that the encoding of that file is UTF-8. This commit improves the implementation of this fixup as follows: * Changed the implementation from using an additional add_custom_command/add_custom_target pair to the much simpler add_custom_command(TARGET _plplotc POST_BUILD ...) signature. The result is the same; the sed fixup occurs *AFTER* whenever swig (re-)generates bindings/python/plplotc.py. * It turns out that this fixup is not needed for Python3 because for that version of Python the default encoding is UTF-8. Therefore, only implement the fixup for the Python2 case. * Because of the new implementation, the _plplotc_fixed target no longer exists. So replace that target with the _plplotc target wherever it occurs in our build system. * Change the comments in README.Release_Manager_Cookbook accordingly. As a result of this commit "_plplotc_fixed" no longer exists in our source tree except for the historical ChangeLog.release file. N.B. Note this remaining small Python2 fixup is actually a workaround for either a Python2 issue (for defaulting to ascii encoding rather than UTF-8) or else swig issue for not working around this Python2 issue. But I have decided not to report this issue because of the uncertainty of where to report it and because it is undoubtedly an uncommon issue that is getting rarer (because Python2's share of the Python market keeps dropping). In fact Python3 is working so well for PLplot, I plan to deprecate and eventually remove our Python2 support (including the current fixup) in the intermediate term (i.e., within a year or two). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by freshly configuring PLplot with either the set of CMake options # The python2 case -DBUILD_TEST=ON --DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DFORCE_PYTHON2=ON or # The (default) python3 case -DBUILD_TEST=ON --DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON For both cases, building the test_diff_psc target showed no configuration, build, run-time, or PostScript difference issues. M README.Release_Manager_Cookbook M bindings/python/CMakeLists.txt M doc/CMakeLists.txt M examples/CMakeLists.txt M examples/python/CMakeLists.txt commit 593c07fcea6402b03c6b9c47842b09284bf2a1b2 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Mar 14 16:22:44 2018 -0700 PLplot build system: configure library builds in a more uniform manner I replaced calls to add_library, target_link_libraries, and the set_library_properties function with a call to the build_library function which for standard libraries can either be static or shared (but not STATIC only and not MODULE). This function calls add_library, creates a namespaced ALIAS library corresponding to that library, calls target_link_libraries in a standard way, and sets standard library properties. Thus, this change significantly reduces the CMake code used to build our libraries and makes sure such building is done in a more uniform way. These new ALIAS libraries will be required in the future (so that the installed libraries can have namespaced targets associated with them so that common code between build tree and install tree can use namespaced library targets). But the future plan is not to confine the use of namespaced targets just to the common code but also use them everywhere in the build tree where a library target is used in a read-only way as a matter of style (and safety for the target_link_libraries item case). So for this commit I used ALIAS library targets in a small way to test them in that context. I also deleted the set_library_properties function since it is no longer used. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the test_noninteractive and test_interactive targets for shared libraries in the build tree without any configure, build, run-time, or PostScript difference issues. M bindings/ada/CMakeLists.txt M bindings/c++/CMakeLists.txt M bindings/d/CMakeLists.txt M bindings/fortran/CMakeLists.txt M bindings/qt_gui/CMakeLists.txt M bindings/tcl/CMakeLists.txt M bindings/wxwidgets/CMakeLists.txt M cmake/modules/plplot_functions.cmake M cmake/modules/plplot_version.cmake M fonts/CMakeLists.txt M lib/csa/CMakeLists.txt M lib/nistcd/CMakeLists.txt M lib/nn/CMakeLists.txt M lib/qsastime/CMakeLists.txt M src/CMakeLists.txt commit ce4c2129fbcbb196a9e9276d1f38fb0c2b25d6a6 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Mar 14 16:21:55 2018 -0700 PLplot build system: update some copyright years M bindings/java/CMakeLists.txt M bindings/lua/CMakeLists.txt M bindings/ocaml/plcairo/CMakeLists.txt M bindings/octave/CMakeLists.txt M bindings/python/CMakeLists.txt M bindings/qt_gui/pyqt4/CMakeLists.txt M bindings/qt_gui/pyqt5/CMakeLists.txt M bindings/qt_gui/smoke/CMakeLists.txt M drivers/CMakeLists.txt M examples/fortran/CMakeLists.txt commit d705381c6cdf99a390bdec22d859e45b5ef13e60 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Mar 13 13:58:27 2018 -0700 PLplot library: Fix bug in command-line parsing for the PL_PARSE_NODELETE case This long-standing bug (which has been revealed by the recent x01c.c change which calls plparseopts with the PL_PARSE_NODELETE option) is the number of command-line options after command-line processing (stored in *p_argc) was being updated when the PL_PARSE_NODELETE option was specified. The result was calls to plparseopts after the first call to that routine in x01c did not have the correct number of command-line options. This commit fixes this bug. I also took this opportunity to improve the documentation of the -pl_parse_skip example option for x01c to make clear that this option must precede any non-PLplot options if the user is to avoid command-line parsing errors for this example. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by running examples/c/x01c (which uses the PL_PARSE_NODELETE option in the first call to plparseopts) with all sorts of different option patterns both with and without the example -pl_parse_skip option. In all cases with -pl_parse_skip I obtained the expected results. If this option preceded zero or more non-PLplot options, the number of options printed out by that option were correct both before and after the call to plparseopts with the PL_PARSE_SKIP option. However, if non-PLplot options preceded -pl_parse_skip, gdb showed the first call to plparseopts with the PL_PARSE_NODELETE option silently failed with the pl_parse_skip_mode variable not set with the subsequent plparseopts call with PL_PARSE_FULL failing (as expected) because of those non-PLplot options. In all cases without -pl_parse_skip I also obtained the expected results (i.e., no command-line option processing errors unless non-PLplot options were used, and the expected interactive or noninteractive plot results.) M examples/c/x01c.c M src/plargs.c commit 734aba7a3e08e7908ae4f2aefa88c64bd94acaab Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Sat Feb 3 21:02:26 2018 +0000 Fixed possible uninitialised variable bug in wxPLplotwindow class There were execution paths where the wxDC pointer would not get initialised before it was passed into the stream in the setUseGraphicsContext method. This is now fixed. Thanks David Bergman for the bug report on the email list. M bindings/wxwidgets/wxPLplotwindow.h commit d2a1a6d61ca0deb9025c019ed9d8d27577beb964 Author: Arjen Markus <arjen.markus@deltares.nl> Date: Sun Jan 7 12:05:39 2018 +0100 Add new routines to the list of exported routines To build the library and the examples with the new routines to parse the command-line arguments we need to export these routines for Intel Fortran. Tested by: Arjen Markus <arjenmarkus@users.sourceforge.net> on bare Windows with the Intel Fortran compiler M bindings/fortran/plplotfortran_ifort.def commit 70ec495533cb117016933f29239e7d2201f6fd9c Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Jan 5 17:51:26 2018 -0800 Fortran binding: Fix dropped specification of the defined region of cstring_address_arg_inout in plparsopts_dynamic This commit fixes a dropped (1:size_local) slice which specifies where cstring_address_arg_inout is defined for the max_cstring_length call. My hope is this change will fix memory management issues encountered by Arjen when he tested plget_arguments_dynamic and plparseopts_dynamic with modern gfortran and ifort. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie with gfortran-4.9.2) by building the plplotfortran binding library without issues. This change could not be tested at run-time because of allocatable length/size character array issues with (the ancient) gfortran-4.9.2. N.B. testing requested for modern gfortran and ifort. M bindings/fortran/plplot.f90 commit 3ee657ef568dc4f16eb0d5ad3d653ce4a10d9ebf Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Jan 2 12:59:15 2018 -0800 Fortran binding: Tweak severe warning messages for parsing API M bindings/fortran/plplot.f90 commit 9fcc4d642ac3d65df16d08098f20dc7179a22570 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Jan 2 12:13:25 2018 -0800 Fortran standard example 01: restore default pl_parse_dynamic = .false. This is to correct my inadvertent commit of a local test case where I set pl_parse_dynamic = .true. M examples/fortran/x01f.f90 commit 6f2f4e4f43f755dcfee28c590e61039cf017de86 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Jan 1 15:31:23 2018 -0800 Fortran binding: implement dynamic length and size and static length and dynamic size variants of plget_arguments and plparseopts These new variants of plget_arguments and plparseopts were added to the existing static length and size variants. In addition, examples/x01f.f90 was updated to test all variants of plget_arguments and plparseopts. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie with gfortran-4.9.2). With this version of gfortran, the dynamic length and size variant of the API did not work at run time, but both the static length and dynamic size and static length and size variants did work. For further details about how to run these tests and the results obtained, see README.release. Additional testing using more modern gfortran versions and other Fortran compilers is requested. M README.release M bindings/fortran/plplot.f90 M bindings/fortran/plplot_small_modules.f90 M examples/fortran/x01f.f90 commit dee0caa5225688b7bcfb6571c12da9db4fbaba69 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Dec 26 16:03:30 2017 -0800 Fortran binding: Fix off-by-one error in plplot_private_utilities::c_to_character_array This routine blanks the tail end of output character array results, and the issue that was fixed was this blanking started one character too soon. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the x01f and ps targets (with the x01f source code locally modified to set pl_parse_skip_mode to .true.) and running software@raven> examples/fortran/x01f xxx -dev psc yyy -o testf.psc zzz argv before call to plparseopts(..., PL_PARSE_SKIP) i = 0, argument = examples/fortran/x01f i = 1, argument = xxx i = 2, argument = -dev i = 3, argument = psc i = 4, argument = yyy i = 5, argument = -o i = 6, argument = testf.psc i = 7, argument = zzz argv after call to plparseopts(..., PL_PARSE_SKIP) i = 0, argument = examples/fortran/x01f i = 1, argument = xxx i = 2, argument = yyy i = 3, argument = zzz PLplot library version: 5.13.0 Before this fix all the trailing i = [0-3] .... results were incorrectly truncated by one letter. M bindings/fortran/plplot_small_modules.f90 commit 71944dbd48f1c29c99252b862e5105b842ca478c Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 25 22:55:51 2017 -0800 C example 01 and Fortran binding and example 01: improvements in command-line parsing The C example improvement was to implement the -pl_parse_skip option for examples/c/x01c.c that demonstrated the existing PL_PARSE_SKIP mode of the C version of plparseopts. The Fortran binding improvement was to make similar PL_PARSE_SKIP mode functionality available for that binding via and added variant of the plparseopts API and a new Fortran function called plget_arguments. The examples/fortran/x01f.f90 improvement was to implement a demonstration of that capability that gave the same results as the corresponding C results. For further details see the write-up concerning these changes in README.release. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie with gfortran-4.9.2) by building the x01c, x01f, and ps targets, and running valgrind in the way described in README.release with perfect results. M README.release M bindings/fortran/included_plplot_real_interfaces.f90 M bindings/fortran/plplot.f90 M bindings/fortran/plplot_small_modules.f90 M examples/fortran/x01f.f90 commit b224a834e4ff3b59a83f97a6e185658e5ed9b768 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Dec 24 15:18:11 2017 -0800 plplot library: fix memory leak in plparseopts if that function is called more than once Each call of plparseopts allocates memory to store plsc->program, and that memory is normally deleted later in plend1. However, if plparseopts is called multiple times with no plend1 call in between ==> memory leak. This commit addresses that issue by freeing non-NULL plsc->program in plparseopts before plsc->program is allocated. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the x01c and ps targets and running valgrind examples/c/x01c.c -dev psc -o testc.psc with perfect results (0 errors, no leaks are possible). Note that example/c/x01c.c is a good test case because it calls plparseopts twice (the first time with PL_PARSE_NODELETE, the second time with PL_PARSE_SKIP or PLPARSE_FULL depending on the results from the first call). Before this fix, the valgrind report showed a memory leak for this example. M src/plargs.c commit 1b0b78f8f158abce519c655a2be3f6ac37115036 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Dec 23 13:51:19 2017 -0800 C standard example 01: implement -pl_parse_skip option for the example Note, the -pl_parse_skip command-line option demonstrates the PL_PARSE_SKIP mode for plparseopts, which parses just the PLplot-relevant options leaving the non-PLplot options for further parsing. Thus, this option demonstrates the first part of how you would parse a mixture of PLplot and non-PLplot command-line options from C, and the long-term intention is to propagate this example option to standard example 01 for fortran first, and then the rest of our supported languages to demonstrate parsing a mixture of PLplot and non-PLplot command-line options is possible for those languages as well. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the x01c and ps targets and running software@raven> examples/c/x01c -pl_parse_skip xxx -dev psc yyy -o test1.psc zzz argv prior to call of plparseopts(..., PL_PARSE_SKIP) i = 0, argument = examples/c/x01c i = 1, argument = -pl_parse_skip i = 2, argument = xxx i = 3, argument = -dev i = 4, argument = psc i = 5, argument = yyy i = 6, argument = -o i = 7, argument = test1.psc i = 8, argument = zzz argv after call to plparseopts(..., PL_PARSE_SKIP) i = 0, argument = examples/c/x01c i = 1, argument = xxx i = 2, argument = yyy i = 3, argument = zzz PLplot library version: 5.13.0 M examples/c/x01c.c commit ef2bf58848be56992f47bb83fbf7ce662d3e612b Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Dec 23 12:02:13 2017 -0800 Style previous commit M bindings/d/plplot.d commit 8aeee637ed0f0d766ca00e1cb25cee4dcb8650b0 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 18 13:13:57 2017 -0800 Build system: fix sanity check logic for set_library_properties function if(NOT(${library}_SOVERSION OR ${library}_VERSION OR LIB_DIR)) ==> if(NOT(DEFINED ${library}_SOVERSION AND DEFINED ${library}_VERSION AND DEFINED LIB_DIR)) As is obvious above the prior version of the logic that has now been fixed was completely bogus (i.e, used OR rather than the correct AND, and used true/false (which failed when ${library}_SOVERSION was 0) rather than doing the correct check that the variable had been DEFINED). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by configuring PLplot with cmake. The result was there were no CMake errors due to the above revision in the sanity checking logic. M cmake/modules/plplot_functions.cmake commit 5c628406e9a1c941dbe34d3db056f985e1ec8b08 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Dec 13 11:06:34 2017 -0800 Build system: Drop the gcc -mieee-fp option on i*86 hardware for the Nan awareness compiler test Orion Poplawski discovered for i686 hardware and the latest gcc and glibc that (a) the gcc -mieee-fp option no longer compiles (apparently because glibc is dropping libieee.a) and (b) the gcc -mieee-fp option is no longer needed for the C NaN awareness test, i.e., when double x = NaN; then x != x is true. Therefore, in this commit I have dropped the -mieee-fp option for the combination of i*86 hardware and gcc. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by configuring PLplot as usual with cmake to confirm that the change introduces no CMake logic errors (and that no special gcc option continues to work for testing C compiler NaN awareness on x86_64 hardware). when double x=NaN, then x != x. M cmake/modules/csiro.cmake commit a7be76715300e829523be309c64d99b1b28c1bcc Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 11 01:43:54 2017 -0800 OCaml examples: fix standard example 33 to solve its inconsistencies with other languages The issue with examples/ocaml/x33.ml was simply that all pages demonstrating plcolobar results (page 5 and beyond) had not been implemented yet, and this commit fixes that issue. N.B. This resolves the last of the long-standing ocaml PostScript differences, and as a result we have gotten a clean PostScript difference report for the first time since 2010! Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by running the test_diff_psc target. The result was perfect PostScript differences (for all our standard examples including the Ocaml ones), e.g., ocaml Missing examples : Differing graphical output : Missing stdout : Differing stdout : and similarly for all the computer languages we support. I also ran valgrind examples/ocaml/x33ocaml -dev psc -o test.psc and the resulting report showed memory leaks (as do all other OCaml examples) but "0 errors from 0 contexts". M README.release M examples/ocaml/x33.ml commit b16d96713747fe027e7b08452c7716aa50fb0fc1 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 11 00:40:10 2017 -0800 Styled previous commit M examples/c/x33c.c commit aa40de75266ae9fc1e24a5be10094b55b867c1a3 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Dec 11 00:36:18 2017 -0800 Core library and bindings: define PL_POSITION_NULL, PL_LEGEND_NULL, and PL_COLORBAR_NULL These option bits are all defined to be zero (0x in some languages, 0 in others) to provide a way to specify no option bits for option arguments to pllegend and plcolorbar. This allows users the (preferred) style choice of always using named option bits rather than numerical constants such as 0x or 0. Furthermore, for certain languages (e.g., OCaml at least) the option bits are stored as part of an enum so until this change it was impossible to use an option bit of zero for any position, legend, or colorbar option. I propagated this update of #defined constants in plplot.h to the bindings by configuring PLplot with -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and by using the following methods (which should be used every time there is such a #defined update of constants): * Run the check_plplotcapi_defines target and copy the generated file back to the appropriate part of bindings/swig-support/plplotcapi.i * Run the check_fortran_parameters target and copy the generated file back to bindings/fortran/included_plplot_parameters.f90 * Run the check_fortran_parameters target and copy the generated file back to bindings/fortran/included_plplot_parameters.f90 * Run the check_tcl_parameters target and copy the generated file back to bindings/tcl/plplot_parameters.h * Used the sed command and remaining instructions documented in bindings/python/Plframe.py to update the constants in that file consistently with bindings/swig-support/plplotcapi.i * Used the sed command and remaining instructions documented in bindings/d/plplot.d to update the constants in that file consistently with bindings/swig-support/plplotcapi.i Note I took this opportunity to collect all the previously hand-crafted constants in one place in plplot.d and work out the sed command (that is documented in the file) to generate those constants automatically. * Appropriate hand-crafted changes to bindings/ocaml files. After those, run the check_plplot_h.inc target and copy the generated file back to bindings/ocaml/plplot_h.inc if different. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by configuring PLplot using the CMake option -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the check_all, test_noninteractive, and test_interactive targets with no obvious configure, build, or run-time errors and no PostScript difference regressions. M bindings/d/plplot.d M bindings/fortran/included_plplot_parameters.f90 M bindings/ocaml/plplot.mli M bindings/ocaml/plplot_core.idl M bindings/ocaml/plplot_h M bindings/ocaml/plplot_impl.c M bindings/python/Plframe.py M bindings/swig-support/plplotcapi.i M bindings/tcl/plplot_parameters.h M include/plplot.h commit ab6649299ba1802f992a92afe4b907d3b703c433 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Dec 10 16:16:11 2017 -0800 Documentation: Update swig documentation to be consistent with recent DocBook documentation update Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by configuring PLplot with -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the check_swig_documentation target without issues. M bindings/swig-support/swig_documentation.i commit 244a526f97bd5d02719394a9121f63e43ec0650c Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Dec 9 12:37:38 2017 -0800 C examples: change -colorbar option to -nocolorbar option for example 33 M examples/c/x33c.c commit 35eafc15523b75616ec37fcb5cacd2b8fcfe470f Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Dec 9 11:01:45 2017 -0800 OCaml examples: Fix inconsistencies with other languages for standard example 16 The cause of this long-standing inconsistency was the use of the high-level OCaml colorbar API for all the color bars in this example. That API is fundamentally inconsistent with the OCaml plcolorbar API because colorbar sets a default color before calling plcolorbar and then restores the original color after that call. And those extra color settings were causing inconsistencies with the results for standard example 16 for other languages. This commit replaced all calls to colorbar by calls to plcolorbar, and that change completely solved the inconsistency. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the test_diff_psc target. The resulting error report for ocaml has all the long-standing example 16 differences removed as a result of this commit, i.e., ocaml Missing examples : Differing graphical output : 33 Missing stdout : Differing stdout : (Those remaining 33 differences are long-standing as well and are caused by that OCaml example being partially implemented, i.e., all the color bar parts of that OCaml example are missing. However, now that the example 16 color bar discrepancies have finally been solved, that future fix should be straightforward.) I also ran valgrind examples/ocaml/x16ocaml -dev psc -o test.psc and the resulting report showed memory leaks (as do all other OCaml examples) but "0 errors from 0 contexts". M bindings/ocaml/plplot_h M examples/ocaml/x16.ml commit e4105d1d1063292c8f33f34cdcc734137f2a59ed Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Dec 9 10:32:27 2017 -0800 Ocaml binding: change indentation and tweak wording of binding description M bindings/ocaml/README commit 601650e3bc4c2cedd9c786dcb6536e7012b3d8a9 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Dec 8 19:01:04 2017 -0800 DocBook documentation: Update pllegend documentation I just noticed the previous nrow and ncolumn argument documentation was completely wrong (obviously copied from another argument entry as a "temporary" place holder), nlegend documentation was outdated, etc. These issues were all fixed by copying wording from the corresponding doxygen documentation of pllegend. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by configuring PLplot with the -DBUILD_DOC=ON cmake parameter, building the html version of the documentation using "make html", and viewing that with a browser. M doc/docbook/src/api.xml commit 0da2c1403fd3a67474065207e3847e7b4f2826f7 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Dec 1 15:03:39 2017 -0800 Add remove_trailing_whitespace.sh to the files that are excluded by that script from being processed by that script The reason why remove_trailing_whitespace.sh should not act on itself is that changes to shell (bash) scripts done while they are executing can potentially mess up their results. M scripts/remove_trailing_whitespace.sh commit 2435390c773fb86584d3b5e761685e3afd3bce3e Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Dec 1 14:17:51 2017 -0800 Website: Update colour scheme The css colour scheme for the PLplot website was developed a bit further for the timeephem project to make the dark text colour absolutely black for best visibility. Adopt this colour change also for the PLplot website. M www/css/CMakeLists.txt M www/css/style.css.in commit d93676de7a9b1481fb463234e93781a32900f8da Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Oct 31 23:28:48 2017 -0700 OCaml bindings and examples: add and use plmap* API The added OCaml API is for plmapline, plmapstring, plmaptex, and plmapfill. I added an "Exmoor" page to the 19th standard OCaml example using this new API to make results from that example consistent with the corresponding C example. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the test_diff_psc target. The resulting error report for ocaml has all the long-standing example 19 differences removed as a result of this commit, i.e., ocaml Missing examples : Differing graphical output : 16 33 Missing stdout : Differing stdout : (Those example 16 and 33 differences are long-standing as well.) I also ran valgrind examples/ocaml/x19ocaml -dev psc -o test.psc and the resulting report showed memory leaks (as do all other OCaml examples) but "0 errors from 0 contexts". M bindings/ocaml/CMakeLists.txt M bindings/ocaml/README M bindings/ocaml/plplot.mli M bindings/ocaml/plplot_core.idl M bindings/ocaml/plplot_impl.c M examples/ocaml/x19.ml commit 76697707c81d7c094a57ab6737d7cf98c0bd5d55 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Oct 31 15:17:17 2017 -0700 OCaml binding: remove gratuitous inconsistencies between plplot_h and plplot.h I recreated plplot_h from the common API declarations in plplot.h with argument types #defined appropriately and using #if 0....#endif preprocessor commands to ignore the parts of the common API (e.g., API with callback arguments) that cannot be processed with touchup.ml. These changes minimize the differences between plplot_h declarations and those in plplot.h, and the results typically have different argument types and argument names and some reordering of the API compared to the previous results. The touchup.ml file had to be changed to be consistent with the a -> alpha argument name change for some of the color map functions. The results of touchup.ml were generated using the cmake option -DADD_SPECIAL_CONSISTENCY_CHECKING=ON, building the check_plplot_h.inc target, and copying back bindings/ocaml/generated_plplot_h.inc in the build tree to bindings/ocaml/plplot_h.inc in the source tree. The resulting plplot_h.inc differences consist solely of argument name changes, one void argument rather than an empty argument, and some reordering of the API. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by configuring PLplot with the cmake option -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the check_plplot_h.inc target without issues and building the test_diff_psc target without obvious configure, build, or run-time issues or PostScript difference regressions. M bindings/ocaml/plplot_h M bindings/ocaml/plplot_h.inc M bindings/ocaml/touchup.ml commit 14d838fc3587cbfe260cccf4106707dd837dfb29 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Oct 31 15:10:33 2017 -0700 Core plplot code: improve alphabetization of common API Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by configuring PLplot with the cmake option -DADD_SPECIAL_CONSISTENCY_CHECKING=ON, and building both the check_all and test_diff_psc targets. The consistency checks run by check_all passed without issues, and there were no configure, build, or obvious run-time issues with the test_diff_psc target and no PostScript difference regressions. M include/plplot.h commit 4e338285ee632e4909de969168ff6d8044748b99 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Oct 31 14:41:56 2017 -0700 Documentation: make API documentation for swig-generated bindings consistent with DocBook API documentation Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the check_swig_documentation target. M bindings/swig-support/swig_documentation.i commit 69067983c65013058cfbe4cf047f0817f1933d37 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Thu Oct 12 19:25:07 2017 -0700 Drop example 17 from -dev wxwidgets tests This was done in the interest of testing convenience because this example takes a considerable length of time to complete for -dev wxwidgets, and this change follows what we have already done for the same reason for -dev qtwidget and -dev xcairo (which are quite slow for this particular example, but still faster than -dev wxwidgets). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie). Note this test was way over the top for this simple change, but I took this opportunity to do complete testing because it was time to do this in any case as a test of previous commits, and also it gave me the opportunity to test a version of CMake that I built myself from the CMake 3.10.0-rc2 source code using the bootstrap method. This test was performed by running (from a source tree with a space in the prefix) time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command ~/cmake/install-3.10.0-rc2/bin/cmake --do_submit_dashboard yes) (Note because of the choice of a "spaced" source tree and the above --prefix, this test has a space in the prefixes of the source, build, and install trees.) Check the results: # Check for any regressions in the warnings in the cmake output. less ../comprehensive_test_disposeable\ blank/shared/noninteractive/output_tree/cmake.out # Check for some non-standard warnings: grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout' # Check for all errors: grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out # Check for any ldd issues for the shared and nondynamic cases. grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results. grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less These checks showed no configure, build, or run-time issues. Furthermore, the last check showed there were no PostScript difference regressions (i.e., the only PostScript difference issues revealed by that check were the long-standing ones for OCaml). In addition, 3 dashboards (for the shared, nondynamic, and static cases) were correctly posted to <http://my.cdash.org/index.php?project=PLplot_git> although with long-standing spurious warning counts for the cmake step which I have been unable to figure out, yet. M plplot_test/test_c_interactive.sh.in commit 14ecc4bd943caa40a830e0da066ff7a220b9d5e8 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Oct 10 19:07:02 2017 -0700 C and C++ source code: replace all use of the WIN32 and __WIN32__ macros with the _WIN32 macro This change fixes bug 189 <https://sourceforge.net/p/plplot/bugs/189/> (which essentially found a Windows compiler that did not set WIN32 but which did set _WIN32). This change is also consistent with a recent list recommendation from Jim Dishaw, and also the (dated) "Windows, Cygwin (non-POSIX), and MinGW" section of <https://web.archive.org/web/20140625123925/http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system>. This fairly intrusive change was done mostly using sed commands for convenience, but because of the possibility of screwing up such commands, this change was reviewed to make sure it did not change too much be reviewing "git diff" results in detail. It was also reviewed to make sure it changed enough by checking our entire source code tree for all instances of WIN32 that had not been converted to _WIN32 to insure all such remaining instances were legitimate ones. Our entire source tree was also checked for remaining occurrences of __WIN32__, and there are none. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the "all" and "test_noninteractive" targets. There were no warning regressions; no obvious configuration, build, or run-time errors; and no PostScript difference regressions. The above tests are just due diligence that none of these Windows-related changes affect Linux results, and fundamental testing of these changes still needs to be done on all the many different Windows platforms we support. M README.release M bindings/tcl/tclAPI.c M bindings/tk-x-plat/plplotter.c M bindings/tk/plframe.c M bindings/tk/pltkd.h M bindings/tk/tcpip.c M bindings/tk/tkMain.c M cmake/epa_build/libharu/cmake.patch M cmake/epa_build/libqhull/src/libqhull.h M drivers/deprecated_wxwidgets_agg.cpp M drivers/pdf.c M drivers/tkwin.c M drivers/wxwidgets_comms.cpp M drivers/wxwidgets_comms.h M drivers/wxwidgets_dev.cpp M examples/c/x22c.c M include/pldll.h.in M lib/csa/csadll.h M lib/csa/nan.h M lib/nistcd/cddll.h M lib/nn/nan.h M lib/nn/nndll.h M lib/qsastime/qsastimedll.h M src/plctrl.c M src/plfreetype.c M src/plstdio.c commit e0d5fdf5df1b619b3f3b3dfe5c082b6fe488e340 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Oct 10 17:59:33 2017 -0700 Fix recently introduced PostScript difference regressions for example 19 These regressions were recently introduced by the plmapfill-> plmapline changes to the C and C++ versions of example 19, and were fixed by propagating these changes to all our supported computer languages other than OCaml (which already has long-standing propagation issues for example 19). Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the test_diff_psc target. As a result the only non-empty PostScript difference summary was ocaml Missing examples : Differing graphical output : 16 19 33 Missing stdout : Differing stdout : These differences are long-standing ones, i.e., we are back to a situation where there are no PostScript difference regressions (compared to e.g., plplot-5.13.0). M examples/ada/xstandard19a.adb M examples/ada/xtraditional19a.adb M examples/d/x19d.d M examples/fortran/x19f.f90 M examples/java/x19.java M examples/lua/x19.lua M examples/octave/x19c.m M examples/python/x19.py M examples/tcl/x19.tcl commit 3fe27f0ecadb14d94a1d5ed9125b35ec82ef67d3 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Fri Oct 6 23:04:36 2017 +0100 WxWidget bug fix for wxWidgets during initialisation The wxPLViewer uses the size of the previously rendered bitmap to test whether or not it needs to rerender on a resize event. However it can receive a resize event before initialising te bitmap and on some platforms that causes a crash/assert fail/exception. Added a check for bitmap initialisation before getting the size of the bitmap. M bindings/wxwidgets/wxPLplotwindow.h commit 3379c4eaa7c4cdebfcc3238bbfe023fb3732e0f9 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Fri Oct 6 00:15:31 2017 +0100 Fixed compile bug in wxPLViewer for gcc GCC is clearly a bit stricter or less clever (depending upon your perspective I guess) than Visual Studio on the format of calling methods of templated classes. Updated the code to fix the compile error given by GCC. M bindings/wxwidgets/wxPLplotwindow.h commit 476ce7392ad45624b41cd761bf1ebd51204fb957 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Thu Oct 5 12:31:32 2017 -0700 Build systems: output additional information The added information is the following: * Full pathname of the cmake executable * Name of generator * CMAKE_INCLUDE_PATH (both cache variable and environment variable forms) * CMAKE_LIBRARY_PATH (both cache variable and environment variable forms) * CMAKE_PLATFORM_INFO_DIR (the location where configured language support files live) I have consistently added this output both for the core build system as well as the CMake-based version of the installed examples build system. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by running cmake in the build tree and observing the output. The install-tree version has not been tested this way, but the identical CMake logic has been copied in that case so it should be fine. M CMakeLists.txt M examples/CMakeLists.txt commit cd8f69d7abe4bc304cfac595fd67af097783dcb1 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Wed Oct 4 23:37:31 2017 +0100 Removed a few lines of code used for debugging that should never have been commited. M utils/wxplframe.cpp commit bb938c8baf3c19b1bff94cc27c073ee9c8bd62bb Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Wed Oct 4 23:36:45 2017 +0100 Style only commit M utils/wxplframe.cpp commit 20069523d621dd6f3a37a6a5b18d344a8ac52c75 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Wed Oct 4 23:32:33 2017 +0100 Fixed recently introduced error that stopped wxPLViewer realizing plotting was complete A recent change accidentally adjusted the logic for a set of if/else statements, meaning that the timer that checks for new data got restarted. The result was a hang with IPC3 comms while the blocking getData function waited for data that never arrived. For non-IPC3 comms the repeated checks had no specific bad effects other than wasted cpu cycles I guess. M utils/wxplframe.cpp commit e4fb932fe67ac431e3ae3205289f58ff1b074a64 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Wed Oct 4 23:24:30 2017 +0100 Set the option of a render delay after resizes on wxPLplotwindows When rendering complex plot resizes can become jerky, unresposive and in some cases impossible because the window is continually trying to rerender the plot. Now set this up so that a delay to the render can be set and after resize the render only happens once the size has remained constant for that delay time. For wxPLviewer that delay time has been set to 1000 ms (1 s). This fixes bug #170 https://sourceforge.net/p/plplot/bugs/170/. M bindings/wxwidgets/wxPLplotwindow.h M utils/wxplframe.cpp commit ff29053fe279e0424cc94c5f4d31a9291d8362a4 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Wed Oct 4 11:30:18 2017 +0100 Attempted workaround for wxPLViewer IPC3 hangs When pllocate is called the core code then requests data from wxPLViewer in a blocking manner. Meanwhile wxPLViewer received the locate instruction, but carried on requesting further plot commands from the core code in a blocking manner while waiting for the user to click the mouse. This caused deadlock. Modified the wxPLViewer code so that it no longer requests data from the core code while waiting for locate data. This sortof works and sometimes allows execution beyond the use of locate in example 20, but then we seem to hit deadlock later. Not sure why. M utils/wxplframe.cpp commit f5974813621b88f7d9e912dc86dde0809b390803 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Tue Oct 3 22:12:09 2017 +0100 Towards correct locate state variable assignment in wxPLViewer I found that the locate state variable should represent the mouse buttons that were down immediately before the mouse event in question. I.e any other buttons held down at the same time or if the event in question was a release, then the button that was released. In theory the logic now in wxPLViewer is correct, but the frame is not capturing button release events so these events are not generating any locate information. This may require use of a wxPanel which I have been meanuing to do anyway as it is best practice. This commit is still an improvement on the incorrect locate information that was being provided though so I thought it was worth commiting now. M utils/wxplframe.cpp commit 5232aaca74724e69e5ad61c12de63d31b44c0151 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Tue Oct 3 15:15:01 2017 +0100 Added support for xor rendering and fixed a locate bug in wxWidgets. Example 20 didn't do the locate part because wxWidgets driver did not support xor mode. added a flag to say this is supported, but actually support isn't really there fully. Support is there when a wxDC is passed into the driver, however when using the wxPLViewer there is an issue - when xor mode is set the draw commands are no longer saved to the buffer, so they never get passed to the viewer. Changing this behaviour will be discussed on the email list. A locate bug was then shown up by this example. When locate occurred on a page other than the first, the PLViewer may have still been on an earlier page. We now record the page on which the locate occurred and do not action it until the user has moved to that page. The three sem comms suffers from a further locate bug which needs further work and is caused by both the core and the viewer code getting stuck sitting and waiting for the other to transmit data. But this commit means that the older comms method deals with locates absolutely correctly. M drivers/wxwidgets.cpp M drivers/wxwidgets.h M drivers/wxwidgets_dev.cpp M utils/wxplframe.cpp M utils/wxplframe.h commit 124a0c3a2745fe6e3060bc61a6ef817e0e41e013 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Mon Oct 2 15:32:16 2017 +0100 Set all clip limit changes I could find to use plP_sclp and hence get recorded in the buffer Clip limits need to be recorded in the buffer in order to be correctly set during a replot. An example of this problem was x33 where legends would not get rendered properly as seen by the wxPLViewer and reported as bug #176 https://sourceforge.net/p/plplot/bugs/176/. I've searched the code for raw assignments of the clip limits and replaced them all with plP_sclp calls in order to make sure that they are recorded in the buffer. I guess the joy of C (vs C++ whee these variables could have been hidden) is that there is nothing stopping people adding new raw assignments. One raw assignment that I left was in plmetafile.c. I couldn't work out why a driver would be modifying the clip limits, so I just left them alone. I will email Jim Dishaw and ask his advice. Tested by running x33c with the wcPLViewer to check all legends are correctly rendered. M src/plcore.c M src/plvpor.c commit 0f71a774d13a1ab67887c291646e0a83360b3fcd Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Mon Oct 2 14:47:54 2017 +0100 Added clipping to the wxWidgets FillPolygon function M drivers/wxwidgets_dev.cpp commit 5b336deacd9de4a16471f1f4a98d12c75d2e5090 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Mon Oct 2 00:08:50 2017 +0100 Fixed crashes associated with -eofill The test to make sure that the PLStream was ready to accept a plP_state call was incorrect. It was testing plsc->initialized !=0, when it should have been checking plsc->level > 0. M src/plargs.c commit 81fafd26e60d3ff4483f4d5bf4c8a666ee758f52 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Sun Oct 1 23:57:22 2017 +0100 Fixed failure to flush with wxViewer This was simply a loop that required exiting to allow rendering when a flush command was received. This fixes bug #169 https://sourceforge.net/p/plplot/bugs/169/ Tested by running example 17 M utils/wxplframe.cpp commit 90692d8fdcfe801a5d4439caa915c4df976e56bb Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Sun Oct 1 23:24:00 2017 +0100 Fixed background clear for wxWidgets driver The unit conversion for getting the region to clear was missing in wxPLDevice::ClearBackground. This has been added. This fixes bug #171 https://sourceforge.net/p/plplot/bugs/171/ Tested by ammending x21 so that each subplot has a different colout background on page 2. M drivers/wxwidgets_dev.cpp commit 315481fa073820302e9c4fb4ffed3c78c60800b3 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Sun Oct 1 12:51:46 2017 +0100 Fixed plreplot and wxPLViewer bugs regarding begining of pages This addressed the bug report at https://sourceforge.net/p/plplot/bugs/168/ There were two issues to address. The first was that if plreplot is called but the PLStream happens to be at the beginning of the page then the new beginning of page (which generally involves clearing the background to the bgcolour set from the buffer) was ignored. Now the status is set to end of page before the buffer read begins. The second issue was that during initialisation wxPLViewer added a beginning of page event to the buffer. It then received the buffer to plot, which included a second beginning of page even and appended this to the existing buffer. This gave two consecutive beginning of page entries in the buffer and the second one (which is the one we actually want) was ignored. This was fixed by checking if the data received was the first data, and if so then overwrite rather than append to the buffer. Tested by running x16 and checking we get correct background colours for all plots. M include/plplotP.h M src/plbuf.c M src/plcore.c M utils/wxplframe.cpp commit b603fd228b29d75f0f3fd2b4b6518e3cf806afe3 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Sun Oct 1 00:38:58 2017 +0100 Fixed wxWidgets even odd winding bug when using viewer This was really a buffer bug or at least the modifications here fix a buffer bug. Basically the dev_eofill variable was not being recorded in the buffer anywhere so it was never passed to the viewer. It is now recorded as part of the the state at beginning of page and plP_state is now called if opt_eofill is called after initialization which causes the state change to be recorded. A new state #define has been added to facilitate this. Tested by Phil Rosenberg by running example 27 with and without the -eofill command argument, however, only up to the point of checking in a debugger that wxPLViewer receives the value and calls the fill function with the correct fill option. I'm not actually sure what the difference in output should be - both looked the same to me, but maybe I'm missing something subtle. M include/plplotP.h M src/plargs.c M src/plbuf.c commit e60fba878d5429592d9c084e18b29f834099189e Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Fri Sep 29 12:26:48 2017 -0700 Fix style and trailing blank issues in a recent commit M doc/docbook/src/api.xml M src/plmap.c commit e3c595819cf8f7596d09be6d4ac0c2beb7e642c3 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Fri Sep 29 12:32:04 2017 +0100 Fixed error in map example 19 The rivers were accidentally plotted with plmapfill not plmapline. This was masked by the fact that before recent fixes the shapefile's render type was always used. M examples/c++/x19.cc M examples/c/x19c.c commit 6fbdc3353d7031278cd803792c226a1d8adf0ae6 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Fri Sep 29 11:49:57 2017 +0100 Fix plmapline plmapline is supposed to override the render type of drawmap, passing in SHPT_ARC as the type to draw, but SHPT_NULL was passed instead causing the type to be derived from the file. Bug spotted and patch sent by Mark de Wever. Thanks for the contribution. M src/plmap.c commit 124674358b7ffe41057d956351e298ddd12a82a9 Author: Arjen Markus <arjen.markus@deltares.nl> Date: Fri Sep 29 11:01:21 2017 +0200 Add scripts and lists of required/recommended packages for Cygwin (64bits) and MinGW/-w64/MSYS2 These scripts are examples of how to run CMake/make and the comprehensive tests for these two platforms. While they have been derived from scripts I have been using for a long time now, I have not tested these cleaned versions thoroughly yet. There may still be some quirks left in or inadvertently left out. The clean-up itself will be useful for me too - lots of stuff had accumulated over time not making it easy to determine what is really needed. Tested but not thoroughly by Arjen Markus (arjen.markus@users.sourceforge.net) A scripts/cygwin/interactive_launch_comprehensive_test.sh A scripts/cygwin/noninteractive_launch_comprehensive_test.sh A scripts/cygwin/package_list.txt A scripts/cygwin/run_cmake.sh A scripts/msys2/interactive_launch_comprehensive_test.sh A scripts/msys2/noninteractive_launch_comprehensive_test.sh A scripts/msys2/package_list.txt A scripts/msys2/run_cmake.sh commit a4d9897f24ef150f8f037d09ff1cac80cd67ce63 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Thu Sep 28 21:19:55 2017 +0100 Fixed the overrides for render type for the maps. The render type passed into drawmap() are now respected. Passing in a SHPT_NULL type causes the type from the file to be used. M doc/docbook/src/api.xml M src/plmap.c commit aadbb28ec27a725eb8475dc67fcf28a23ec7d50a Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Thu Sep 28 20:51:59 2017 +0100 Restyle only commit M include/plplot.h M src/plmap.c commit 57e50d8bfdc4c3e687ec8347de1257cb257ed967 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Thu Sep 28 20:41:43 2017 +0100 Edited plmap documentation This now reflects the changes made in the previous two commits and the fact that shapelib is required for maps. M doc/docbook/src/api.xml commit 0b7dc2d42f29eed1780c01d1814ee5ddd9901dd8 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Thu Sep 28 20:01:49 2017 +0100 Cleared out some unused functions from plmap.c M src/plmap.c commit 7e7acff15a6eb8aff3b13d94740622b571f0ad77 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Thu Sep 28 19:50:41 2017 +0100 Fixed PLFLT issue in plmap and issue with polygons wrapping the globe There was a problem with array types if PLFLT was not a double. this got introduced because shapelib always deals in doubles and in the last commit the conversion got removed. It has been added back in a more useful place. Also dealt with plmap rendering of polygons that wrap the whole globe, e.g. Antarctica. We should also effectively deal with the case where such a polgon gets turned inside out, like when doing a polor plot with the north pole in the centre. M src/plmap.c commit 47222ff73c8410dc717ed4886e2ea88e06f5649e Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Thu Sep 28 18:21:37 2017 +0100 Massively simplified the map code to fix a rendering bug and added PLFLT_HUGE_VAL to plplot.h A rendering bug was reported - see email to the list to the plplot-devel list entitled Plmap omits lines at the left hand side of the map dated 18th Nov 2016. The bug was as described, lines on a lat/lon map that touched the left edge of the plot dissapeared. I have removed the code that tried to be clever and wrap cut sections of lines that weren't supposed to be plotted and attempted to wrap them round the globe if needed. Instead I now draw objects multiple times if needed to cover the wraparound. Note we also now support doing a plot which loops round the globe multiple times, so for example you could do lon -180 to +540 and you would get two full renderings of the globe. I added PLFLT_HUGE_VAL as I wanted to ensure that if someone threw one of the floating point limiting values in as the limit for the map plot then I wouldn't get stuck in a near infinite loop. M include/plplot.h M src/plmap.c commit 0f3dcb2acf1df511a9a4299079234853043458c3 Author: Phil Rosenberg <p.d.rosenberg@gmail.com> Date: Thu Sep 28 15:29:51 2017 +0100 Comments and minor tidy in plmap.c Just added and edited some comments. Also removed reading the max/min values from the shapefile as we don't use these values anywhere. M src/plmap.c commit a52aa2ff0dd371bc86784c58a4b1538eaa4ac2c6 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Sep 25 12:52:54 2017 -0700 Update our source tree from plplot.sourceforge.net (or plplot.sf.net) to plplot.org As a result of this change the command find . -type f |grep -v .git |xargs grep -El 'plplot.sf.net|plplot.sourceforge.net' yields only the following list of historical files ./rpm/plplot_mandrake9.2.spec ./rpm/plplot_redhat7.3.spec ./rpm/plplot_mandrake8.1.spec ./rpm/plplot_mandrake8.0.spec ./rpm/plplot_redhat6.2.spec ./rpm/plplot_redhat7.2.spec ./rpm/plplot_redhat7.1.spec ./README.release ./README.cumulated_release ./www/announce/announce-plplot-5.2.1.html ./www/announce/announce-plplot-5.1.0.html ./www/announce/announce-plplot-5.3.0.xml ./www/announce/announce-plplot-5.3.1.xml ./www/announce/ChangeLog-5.3.0-5.3.1 Tested by: Alan W. Irwin <airwin@users.soureforge.net> on Linux by running echo irwin$'\n'irwin$'\n'raven$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh and confirming there are no warning regressions or errors using find /tmp/plplotdoc -name '*.out' |xargs grep -i warning |less find /tmp/plplotdoc -name '*.out' |xargs grep -i error |grep -vE 'unable to read file loc from' (That grep -vE stanza is to remove output lines from doxygen that tend to include some case variants of "error" in the string because the referred to function name contains that substring.) I also very superficially checked the locally generated website to, e.g., confirm the internal references are to plplot.org and not plplot.sf.net. However, that check also showed obsolete/deprecated functions had been changed due to all the recent cruft removal. So because of these post-5.13.0 cruft-removal changes, I have decided not to upload the locally generated website to SourceForge so that site will still contain internal references to plplot.sf.net and plplot.sourceforge.net until the next release when the regenerated website will automatically be uploaded as part of the usual release process. N.B. www/README.domain still needs to be created to explain in detail what we need to do in the future to maintain plplot.org and www.plplot.org. M NEWS M README M README.Release_Manager_Cookbook M README.release M bindings/ocaml/README M bindings/tk/about.tcl M cmake/modules/docbook.cmake M doc/docbook/README.developers M doc/docbook/src/intro.xml M doc/pstex2eps.1 M drivers/README.wxwidgets M www/announce/CMakeLists.txt commit c275d59fe6059899fbf49587a20db9ce57e6235c Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Sep 10 17:39:08 2017 -0700 Substantially update the history of our DocBook documentation project M doc/docbook/README commit f997464d2e173137e3cb33d3d99f03a7bfdaa428 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Sep 25 11:45:07 2017 -0700 Fix @param Doxygen bug M src/plmem.c commit 53b33bdd81580e8a09aa1ae9c7dc8752d0c4b4e6 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Thu Sep 21 08:43:58 2017 -0700 Official deprecation of C++ cruft Thirteen C++ methods (see README.release for the full list) have been unoffically deprecated (via comments in the code and lack of use in our C++ examples) for a long time. One of these is the unofficially deprecated (AND incorrect) historical name "col" for the col1 method, and the rest are unofficially deprecated versions of methods which use PLINT instead of bool for logical arguments. With this commit, these unofficially deprecated methods have now been officially deprecated, i.e., they will only be accessible if a user sets -DPL_DEPRECATED=ON. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie). The following tests were all done in the build tree for the shared libraries case: * Built the "all" target for -DPL_DEPRECATED=ON * Built the "all" target for -DPL_DEPRECATED=OFF * Built the "test_noninteractive" target for -DPL_DEPRECATED=OFF * Built the "test_interactive" target for -DPL_DEPRECATED=OFF In all cases there were no configure-, build-, or run-time errors and no warning regressions. For the "test_noninteractive" case, there were no PostScript difference regressions. M README.release M bindings/c++/plstream.cc M bindings/c++/plstream.h commit 6ce0494ec5542cb4f8fd89e22c7ce9ead8332d2a Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 20 21:53:14 2017 -0700 Remove trailing whitespace from recent commit M doc/docbook/src/api-c.xml commit 079cbf1f283cf82fc62eaf936423d65614fe584a Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 20 11:08:52 2017 -0700 C and C++ API: Implement plStatic2dGrid and deprecate plshade1 The 2D matrix arguments of plshade, plshades, plcont, plimage, plvect, etc., for our C API and corresponding C++ API must currently be organized as Iliffe column vectors (see <https://en.wikipedia.org/wiki/Iliffe_vector>) containing pointers to PLFLT row vectors. And these matrices are normally in the C case dynamically allocated with plAlloc2dGrid and freed with plFree2dGrid, and in the C++ case the same thing is done with C++ wrappers for plAlloc2dGrid and plFree2dGrid. However, that dynamically allocated approach has not allowed our C and C++ users to call plshade, etc., with statically allocated 2D data. Historically we have partially addressed that issue by implementing a plshade1 variant of plshade that could be called with a statically allocated 2D matrix. Expanding that approach with plshades1, plcont1, etc., variants is possible, but does considerably clutter our C and C++ API. So instead for this release we have implemented the plStatic2dGrid C function and associated C++ wrapper which allows C and C++ users to determine the Iliffe column vector corresponding to a 2D statically allocated array. The standard C and C++ examples (specifically examples/c/x15c.c and examples/c++/x15.cc) demonstrate how to use this new approach to call plshade using 2D data that have been statically allocated, and although none of our examples illustrate these additional possibilities, this same approach could also be used to call plshades, etc., with 2D data that have been statically allocated. I have added DocBook documentation of plStatic2dGrid and also significantly updated our DocBook documentation of the 2D matrix API for C consistent with this new C (and C++) functionality. Since this new approach completely supersedes plshade1, we have officially deprecated that function and its C++ wrapper. (Note this is a backwards-incompatible change to our C and C++ API's. Such official deprecation means that plshade1 and its C++ wrapper are only available to users if they specify the -DPL_DEPRECATED=ON cmake option. And our DocBook documentation for plshade1 has been moved to the obsolete/deprecated section of that documention. This deprecation means that all other references to plshade1 (except for historical data such as change logs and release notes) to plshade1 have been eliminated from our source tree with this commit. In particular, plshade1 had (in error) been previously propagated to the Ada traditional binding as plshade1 and Ada standard binding as Shade_Region_1, and used in the Ada standard and traditional examples so plshade1 and Shade_Region_1 have been dropped from the Ada bindings (note, this is a backwards-incompatible change for those bindings) and replaced in the Ada examples with the corresponding calls to plshade and Shade_Region. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie). These tests consisted of the following steps: * I checked that the goal of elimination of references in our source tree to shade1 had been achieved (except for the C and C++ deprecated API, the obsolete/deprecated DocBook documentation, and historical data) using find . -type f |grep -v .git |xargs grep shade1 |less and find . -type f |grep -v .git |xargs grep Shade_Region_1 |less * Using the cmake option -DBUILD_DOC=ON, I built the "html" target and checked that build of the html form of our documentation worked without validation issues and produced good results for the documentation of plStatic2dGrid, our general 2D matrix documentation for our C API, and the deprecated plshade1 documentation. * For both the -DPL_DEPRECATED=OFF and ON cases, I built the test_diff_psc target without configure, build, or run-time issues, and without any regressions in PostScript difference results. * I ran valgrind examples/c/x15c -dev psc -o test.psc and valgrind examples/c++/x15 -dev psc -o test.psc The resulting valgrind reports were perfect (i.e., "All heap blocks were freed -- no leaks are possible" and "ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)" ) which demonstrates that the new plStatic2dGrid C functionality and its C++ wrapper that are used in these examples introduce no memory management issues. M README.Release_Manager_Cookbook M bindings/ada/plplot_standard.adb M bindings/ada/plplot_standard.ads M bindings/ada/plplot_thin.ads M bindings/ada/plplot_traditional.adb M bindings/ada/plplot_traditional.ads M bindings/c++/plstream.cc M bindings/c++/plstream.h M bindings/ocaml/plplot_impl.c M bindings/python/plplotc.i M bindings/swig-support/plplotcapi.i M doc/docbook/src/api-c.xml M doc/docbook/src/api-obsolete.xml M doc/docbook/src/api.xml M doc/docbook/src/c.xml M doc/docbook/src/plplotdoc.xml.in M examples/ada/xstandard15a.adb M examples/ada/xtraditional15a.adb M examples/c++/x15.cc M examples/c/x15c.c M include/plplot.h M src/plmem.c M src/plshade.c commit 22a3bad9d3aaf6921e8099b7ee87460e4b038c24 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 20 11:05:07 2017 -0700 Update release notes for next release Describe new pyqt[45] configuration scheme and soon-to-be committed implementation of plStatic2dGrid and corresponding deprecation of plshade1. M README.release commit 5f7e54119679d79c111bf37128ef441b56914d2e Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Sep 18 19:17:39 2017 -0700 Simplify plapi.tpl by dropping all commented-out parts of the file Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the test_diff_psc target in the build tree for the shared library case with no PostScript difference regressions. M bindings/tcl/plapi.tpl commit 5d2c57322f9bb78ef5d055e9439cf2efa012da64 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Sep 18 15:20:32 2017 -0700 Simplify plplot_h by dropping all commented-out parts of the file Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by configuring PLplot with the DADD_SPECIAL_CONSISTENCY_CHECKING=ON option and building the check_plplot_h.inc target which checks that bindings/ocaml/plplot_h.inc is consistent with what should be same file generated with bindings/ocaml/touchup.ml from bindings/ocaml/bindings/ocaml/plplot_h where all three mentioned files are in the source tree. M bindings/ocaml/plplot_h commit 7c53539e300ac99c0db436c228fccf6b4d63338d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Sep 12 16:53:19 2017 -0700 Fix bug in check_api_completeness.sh This script previously failed because it referred to files associated with the old fortran binding that has now been removed, and the fix was to gather similar Fortran API information from the new fortran binding. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by running scripts/check_api_completeness.sh all |less in the source tree. The script now finishes without errors although it currently reveals some possible API inconsistencies which might be real or which might be artifacts of how the various API results have been parsed. So those possible API inconsistencies need to be investigated further. M scripts/check_api_completeness.sh commit 696e56be6bb027d602de30120b6a12aa90d06c6f Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Sep 12 16:49:33 2017 -0700 Remove all officially deprecated functions I removed plParseInternalOpts, plSetInternalOpt, plclr, plpage, plcol, plcontf, plP_gvpd, plP_gvpw, plotsh3d, plSetOpt, plrgb, plrgb1, plhls, and plwid. These functions were officially deprecated (i.e., only accessible if the user specifed the -DPL_DEPRECATED=ON cmake option) as of the PLplot-5.9.10 release (and in some cases even before that release) so it is long past the time to remove them. I also edited the source tree files to remove all mentions of these functions (as well as plParseOpts, plHLS_RGB, plRGB_HLS, and plarrows that had been previously removed). As a result find . -type f |grep -v .git |xargs grep -E 'plParseInternalOpts|plSetInternalOpt|plclr|plpage|plcol|plcontf|plP_gvpd|plP_gvpw|plotsh3d|plSetOpt|plrgb|plrgb1|plhls|plwid' |grep -vE 'plcol0|plcol1|plcolorbar' |less and find . -type f |grep -v .git |xargs grep -E 'plParseOpts|plHLS_RGB|plRGB_HLS|plarrows' |less now only find non-relevant hits or else hits for historical references (e.g., change logs and release notes) to these functions. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) for the build-tree shared-library case by configuring the PLplot build using the -DADD_SPECIAL_CONSISTENCY_CHECKING=ON cmake option, and building the validate and check_all targets with no issues. I built the check_api_xml_consistency target which generated the same c_plshade1 and plGetCursor inconsistencies as previously (i.e., this target revealed no regressions from previous results due to the present changes). Finally, I built the test_interactive and test_noninteractive targets and checked those results as follows: # Check for any regressions in the warnings in the cmake output. less cmake.out # Check for some non-standard warnings: grep -i warning *.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout' # Check for all errors: grep -i error *.out # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results. grep -B1 -A3 "Missing examples" test_noninteractive.out |less These checks showed no issues other than long-standing PostScript differences for ocaml (i.e., there were no PostScript difference regressions). M FAQ M README.release M bindings/ada/plplot_standard.adb M bindings/ada/plplot_standard.ads M bindings/ada/plplot_thin.ads M bindings/ada/plplot_traditional.adb M bindings/ada/plplot_traditional.ads M bindings/c++/plstream.cc M bindings/c++/plstream.h M bindings/d/plplot.d M bindings/java/PLStream.java M bindings/lua/plplotluac.i M bindings/ocaml/plplot_h M bindings/octave/PLplot/arrows.m M bindings/octave/PLplot/figure.m M bindings/octave/PLplot/shade.m M bindings/octave/PLplot/support/__pl_contour.m M bindings/octave/PLplot/support/__pl_plotit.m M bindings/python/Plframe.py M bindings/swig-support/CMakeLists.txt M bindings/swig-support/plplotcapi.i M bindings/tcl/plapi.tpl M doc/docbook/src/api-obsolete.xml M include/plplot.h M scripts/check_api_completeness.sh M src/plargs.c M src/plcont.c M src/pldeprecated.c M src/plmem.c commit ddd516cc9d8ab817da1625cad318dc65a7d33f0a Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Sep 12 13:52:40 2017 -0700 Remove the rest of the sys subdirectory tree The "sys" subdirectory tree was originally used in the pre-CMake days to implement various build systems for various platforms. Most of this subdirectory tree was removed in commit 69abf21 (2009-09-23) followed by the removal of sys/dos/djgpp in commit aaf7332 (2010-01-25). This left just sys/win-tk. However, that directory has not been developed for a decade or more, and my scan through the files there showed there was nothing left of value there so I have removed this last of the "sys" subdirectories in this commit. M CMakeLists.txt D sys/win-tk/Readme.txt D sys/win-tk/makePlplotStarkit.tcl D sys/win-tk/makefile.vc D sys/win-tk/pkgIndex.tcl D sys/win-tk/plConfig.h D sys/win-tk/plDevs.h D sys/win-tk/tclIndex D sys/win-tk/tclgen.c D sys/win-tk/tclgen.h D sys/win-tk/tclgen_s.h D sys/win-tk/testPlplot.tcl commit 90723a2fa7e02899501497f461e29ba836db330d Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Tue Sep 12 12:14:47 2017 -0700 Remove unused global-in-scripts file in octave binding D bindings/octave/globals-in-scripts commit 8d13579ae3042b26b8746563b8b7752181737639 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Thu Sep 7 15:35:53 2017 -0700 Perl/PDL examples removal By historical accident and for just a limited time we actively developed a set of standard examples written in Perl/PDL to help test Doug Hunt's external PDL::Graphics::PLplot project. But we have now removed those examples from our project since we have long since stopped testing PDL::Graphics::PLplot with those examples, and, in any case, such examples should be part of PDL::Graphics::PLplot rather than PLplot. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the test_noninteractive, validate, and install targets in the build tree for the shared library case. There were no obvious configuration or run-time issues, and no PostScript difference regressions. M ABOUT M README.release M README.testing M bindings/swig-support/swig_documentation.i M bindings/tk/about.tcl D cmake/modules/pdl.cmake M cmake/modules/plplot.cmake M cmake/modules/summary.cmake M doc/docbook/src/CMakeLists.txt M doc/docbook/src/api.xml D doc/docbook/src/perl.xml M doc/docbook/src/plplotdoc.xml.in M doc/docbook/src/schemas.xml M examples/CMakeLists.txt M examples/Makefile.examples.in D examples/perl/CMakeLists.txt D examples/perl/README.perldemos D examples/perl/check-sync.pl D examples/perl/x01.pl D examples/perl/x02.pl D examples/perl/x03.pl D examples/perl/x04.pl D examples/perl/x05.pl D examples/perl/x06.pl D examples/perl/x07.pl D examples/perl/x08.pl D examples/perl/x09.pl D examples/perl/x10.pl D examples/perl/x11.pl D examples/perl/x12.pl D examples/perl/x13.pl D examples/perl/x14.pl D examples/perl/x15.pl D examples/perl/x16.pl D examples/perl/x17.pl D examples/perl/x18.pl D examples/perl/x19.pl D examples/perl/x20.pl D examples/perl/x21.pl D examples/perl/x22.pl D examples/perl/x23.pl D examples/perl/x24.pl D examples/perl/x25.pl D examples/perl/x26.pl D examples/perl/x27.pl D examples/perl/x28.pl D examples/perl/x29.pl D examples/perl/x30.pl D examples/perl/x31.pl D examples/perl/x33.pl M examples/plplot_configure.cmake_installed_examples.in M plplot_test/CMakeLists.txt M plplot_test/plplot-test.sh.in M plplot_test/test_diff.sh.in D plplot_test/test_pdl.sh.in commit ce9f7bb6e9d605cb4302c409ae06e9e46f879abe Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 6 11:29:09 2017 -0700 Remove trailing whitespace from a previous commit M cmake/modules/qt.cmake commit 51415db8b5d88657215a02b54694d5102c36e4e2 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 6 11:21:49 2017 -0700 Build system: remove remaining references to *.map files in our source tree These *.map files were all removed in a prior commit so they no longer have to be specifically identified as binary data (.gitattributes) or excluded from consideration (scripts/parity_bit_check.exclude AND scripts/remove_trailing_whitespace.sh). All other references to '\.map' in our source tree that were found using find . -type f |grep -v .git |xargs grep '\.map' |less turned out not to be references to *.map files. M .gitattributes M scripts/parity_bit_check.exclude M scripts/remove_trailing_whitespace.sh commit 2ac4b7b530ed023b037c390b6dff1a57a30d2981 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 6 10:56:18 2017 -0700 plmap cruft removal As of PLplot-5.9.10, a new version of plmap was implemented that used shapefile format (accessed via shapelib) for maps. In addition other powerful map API (see the last page of standard example 19) that depended on shapelib map data was implemented as well. However, we still made the old plmap implemention that depended on the (undocumented) binary format of our *.map files available when the user specified -DPL_DEPRECATED=ON, and this arrangement continued through PLplot-5.13.0. However, it appears our users are generally satisfied with the new shapefile-based plmap functionality and we no longer want to maintain or test that old plmap functionality based on the *.map format. So for this commit that old plmap functionality and associated *.map files have been completely removed from our source tree. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the test_diff_psc and install targets in the build tree for the shared library case. I did the above test twice (once as per normal and once with a temporary local variation of cmake/modules/FindShapelib.cmake that disabled finding of shapelib). In both cases there were no obvious configuration or run-time issues, and the PostScript difference results had no regressions. And (as expected) when shapelib finding was disabled, example 19 generated plot results with no map information other than meridians (from the calls in that example to plmeridians) and labels, and the core plplot library (as expected) emitted "PLPLOT WARNING" messages with the following messages: plmap is a no-op because shapelib is not available. plmapfill is a no-op because shapelib is not available. plmapline is a no-op because shapelib is not available. plmaptex is a no-op because shapelib is not available. M README.release M data/CMakeLists.txt D data/cglobe.map D data/globe.map D data/usa.map D data/usaglobe.map M src/CMakeLists.txt D src/deprecated_plmap.c commit e3e0f15134128e76ec37e99285eae13a56b3dff0 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Wed Sep 6 01:36:50 2017 -0700 Build system: Update NAMES used to find PYQT_SIP_DIR This update is based on the following results from Arjen's run of the "pkgfile -v QtCoremod.sip" command on his MinGW-w64/MSYS2 platform: mingw32/mingw-w64-i686-python2-pyqt4 4.11.4-2 /mingw32/share/sip/Py2-Qt4/QtCore/QtCoremod.sip mingw32/mingw-w64-i686-python2-pyqt5 5.8-1 /mingw32/share/sip/Py2-Qt5/QtCore/QtCoremod.sip mingw32/mingw-w64-i686-python3-pyqt4 4.11.4-2 /mingw32/share/sip/PyQt4/QtCore/QtCoremod.sip mingw32/mingw-w64-i686-python3-pyqt5 5.8-1 /mingw32/share/sip/PyQt5/QtCore/QtCoremod.sip mingw64/mingw-w64-x86_64-python2-pyqt4 4.11.4-2 /mingw64/share/sip/Py2-Qt4/QtCore/QtCoremod.sip mingw64/mingw-w64-x86_64-python2-pyqt5 5.8-1 /mingw64/share/sip/Py2-Qt5/QtCore/QtCoremod.sip mingw64/mingw-w64-x86_64-python3-pyqt4 4.11.4-2 /mingw64/share/sip/PyQt4/QtCore/QtCoremod.sip mingw64/mingw-w64-x86_64-python3-pyqt5 5.8-1 /mingw64/share/sip/PyQt5/QtCore/QtCoremod.sip Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by using all 4 combinations of -DFORCE_PYTHON2=OFF (or ON) -DPLPLOT_USE_QT5=OFF (or ON) and verifying the correct PYQT_SIP_DIR was found in each case. M cmake/modules/qt.cmake commit b96ced11d61185d7621abc4412332e51093e23f8 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Mon Sep 4 11:22:18 2017 -0700 Tcl/Tk cruft removal As of PLplot-5.12.0, a new Tcl binding was implemented that used the "redacted" PLplot API where all dimension arguments for arrays are dropped from argument lists since those data are redundant (already supplied by the arrays themselves). As a result of this change, Tcl calls to the PLplot API in the old binding such as $w cmd plline $nsize x y now have to be replaced in the new binding by $w cmd plline x y and similarly for all other Tcl calls to the PLplot API that involve array (tclmatrix) arguments. The advantages of this new binding are it is cleaner, it is safer (i.e., automatically self-consistent with regard to array dimensions), and it makes our Tcl binding compatible with the rest of our bindings. (The only exception to this is our C++ binding which currently still uses simple C-style arrays and therefore must use the non-redacted form of the PLplot API, but that may also change in the future.) However, the disadvantage of this change is our new binding is obviously backwards-incompatible with the old binding. Therefore, for PLplot-5.12.0 we implemented the CMake option -DUSE_NON_REDACTED_TCL_TK=ON to provide temporary deprecated access to the old Tcl binding, and that form of backwards compatibility continued to be provided for the PLplot-5.13.0 release. However, it appears our users are generally satisfied with the new binding, and we no longer want to maintain or test that old binding. So for this commit the old Tcl binding (and old versions of the Tcl standard examples and Tk source code that depended on it) have been completely removed from our source tree. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building (for the shared library case) the test_noninteractive and test_interactive targets in the build tree as follows: cmake .... <defaults for everything> >& cmake.out make -j4 test_noninteractive >& test_noninteractive.out make -j4 test_interactive >& test_interactive.out These results were checked as follows: # Check for any regressions in the warnings in the cmake output. less cmake.out # N.B. the --binary-files=text option below is required because some binary data # (a group of NULL characters) got into test_noninteractive.out. (This is a long-standing # bug which I plan to investigate later.) # Check for some non-standard warnings: grep --binary-files=text -i warning *.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout' # Check for all errors: grep --binary-files=text -i error *.out # Check for any PostScript or Text differences between all non-C languages and the corresponding # C results. grep --binary-files=text -B1 -A3 "Missing examples" test_noninteractive.out |less These checks showed no issues other than long-standing PostScript differences for ocaml (i.e., there were no PostScript difference regressions). M README.release M bindings/CMakeLists.txt D bindings/non_redacted_tcl/CMakeLists.txt D bindings/non_redacted_tcl/README.tclAPI D bindings/non_redacted_tcl/global_defines.sed D bindings/non_redacted_tcl/matrixInit.c D bindings/non_redacted_tcl/pkgIndex.tcl.in D bindings/non_redacted_tcl/plapi.tpl D bindings/non_redacted_tcl/plitclgen D bindings/non_redacted_tcl/plitclgen.tcl D bindings/non_redacted_tcl/plplot_parameters.h D bindings/non_redacted_tcl/pltcl.c D bindings/non_redacted_tcl/pltcl.h D bindings/non_redacted_tcl/pltclgen D bindings/non_redacted_tcl/pltclgen.tcl D bindings/non_redacted_tcl/tclAPI.c D bindings/non_redacted_tcl/tclMain.c D bindings/non_redacted_tcl/tclMatrix.c D bindings/non_redacted_tcl/tclMatrix.h D bindings/non_redacted_tcl/tclcmd.tpl D bindings/non_redacted_tk-x-plat/CMakeLists.txt D bindings/non_redacted_tk-x-plat/Memberscope.tcl D bindings/non_redacted_tk-x-plat/Plplotter_Init.c D bindings/non_redacted_tk-x-plat/Plplotwin.tcl D bindings/non_redacted_tk-x-plat/Plwindow.tcl D bindings/non_redacted_tk-x-plat/pkgIndex.tcl.in D bindings/non_redacted_tk-x-plat/plbarchart.tcl D bindings/non_redacted_tk-x-plat/plplotter.c D bindings/non_redacted_tk-x-plat/pltimeseries.tcl D bindings/non_redacted_tk-x-plat/pltkwd.h D bindings/non_redacted_tk-x-plat/plwidget2.tcl D bindings/non_redacted_tk-x-plat/tclIndex D bindings/non_redacted_tk/CMakeLists.txt D bindings/non_redacted_tk/FileSelector.tcl D bindings/non_redacted_tk/PLWin.itk D bindings/non_redacted_tk/PLXWin.itk D bindings/non_redacted_tk/Pltk_Init.c D bindings/non_redacted_tk/Pltkwin.tcl D bindings/non_redacted_tk/about.tcl D bindings/non_redacted_tk/app-defaults/PLplot.large.ad D bindings/non_redacted_tk/app-defaults/PLplot.medium.ad D bindings/non_redacted_tk/app-defaults/PLplot.small.ad D bindings/non_redacted_tk/app-defaults/README D bindings/non_redacted_tk/cmap0a.pal D bindings/non_redacted_tk/cmap1a.pal D bindings/non_redacted_tk/cmap1a1.pal D bindings/non_redacted_tk/cmap1b.pal D bindings/non_redacted_tk/cmap1c.pal D bindings/non_redacted_tk/cmap1d.pal D bindings/non_redacted_tk/help_gui.tcl D bindings/non_redacted_tk/help_keys.tcl D bindings/non_redacted_tk/help_tcltk.tcl D bindings/non_redacted_tk/pkgIndex.tcl.in D bindings/non_redacted_tk/plclient.tcl D bindings/non_redacted_tk/plcolor.tcl D bindings/non_redacted_tk/plconfig.tcl D bindings/non_redacted_tk/pldefaults.tcl D bindings/non_redacted_tk/plframe.c D bindings/non_redacted_tk/plplot.tcl D bindings/non_redacted_tk/plr.c D bindings/non_redacted_tk/plserver.c D bindings/non_redacted_tk/plserver.h D bindings/non_redacted_tk/plserver.tcl D bindings/non_redacted_tk/pltk.h D bindings/non_redacted_tk/pltkd.h D bindings/non_redacted_tk/pltools.tcl D bindings/non_redacted_tk/plwidget.tcl D bindings/non_redacted_tk/stupidtk.c D bindings/non_redacted_tk/tcpip.c D bindings/non_redacted_tk/tcpip.h D bindings/non_redacted_tk/tkMain.c D bindings/non_redacted_tk/tkshell.c M cmake/modules/tcl-related.cmake M cmake/modules/tk.cmake M doc/Doxyfile.in M examples/CMakeLists.txt D examples/non_redacted_tcl/CMakeLists.txt D examples/non_redacted_tcl/README.tcldemos D examples/non_redacted_tcl/plgrid.tcl D examples/non_redacted_tcl/plot.dat D examples/non_redacted_tcl/plot.tcl D examples/non_redacted_tcl/pltcl_standard_examples.in D examples/non_redacted_tcl/r.dat D examples/non_redacted_tcl/stats.log D examples/non_redacted_tcl/tcldemos.tcl D examples/non_redacted_tcl/tclsh_standard_examples.in D examples/non_redacted_tcl/x00 D examples/non_redacted_tcl/x00.tcl D examples/non_redacted_tcl/x01 D examples/non_redacted_tcl/x01.tcl D examples/non_redacted_tcl/x02 D examples/non_redacted_tcl/x02.tcl D examples/non_redacted_tcl/x03 D examples/non_redacted_tcl/x03.tcl D examples/non_redacted_tcl/x04 D examples/non_redacted_tcl/x04.tcl D examples/non_redacted_tcl/x05 D examples/non_redacted_tcl/x05.tcl D examples/non_redacted_tcl/x06 D examples/non_redacted_tcl/x06.tcl D examples/non_redacted_tcl/x07 D examples/non_redacted_tcl/x07.tcl D examples/non_redacted_tcl/x08 D examples/non_redacted_tcl/x08.tcl D examples/non_redacted_tcl/x09 D examples/non_redacted_tcl/x09.tcl D examples/non_redacted_tcl/x10 D examples/non_redacted_tcl/x10.tcl D examples/non_redacted_tcl/x11 D examples/non_redacted_tcl/x11.tcl D examples/non_redacted_tcl/x12 D examples/non_redacted_tcl/x12.tcl D examples/non_redacted_tcl/x13 D examples/non_redacted_tcl/x13.tcl D examples/non_redacted_tcl/x14 D examples/non_redacted_tcl/x14.tcl D examples/non_redacted_tcl/x15 D examples/non_redacted_tcl/x15.tcl D examples/non_redacted_tcl/x16 D examples/non_redacted_tcl/x16.tcl D examples/non_redacted_tcl/x17 D examples/non_redacted_tcl/x17.tcl D examples/non_redacted_tcl/x18 D examples/non_redacted_tcl/x18.tcl D examples/non_redacted_tcl/x19 D examples/non_redacted_tcl/x19.tcl D examples/non_redacted_tcl/x20 D examples/non_redacted_tcl/x20.tcl D examples/non_redacted_tcl/x21 D examples/non_redacted_tcl/x21.tcl D examples/non_redacted_tcl/x22 D examples/non_redacted_tcl/x22.tcl D examples/non_redacted_tcl/x23 D examples/non_redacted_tcl/x23.tcl D examples/non_redacted_tcl/x24 D examples/non_redacted_tcl/x24.tcl D examples/non_redacted_tcl/x25 D examples/non_redacted_tcl/x25.tcl D examples/non_redacted_tcl/x26 D examples/non_redacted_tcl/x26.tcl D examples/non_redacted_tcl/x27 D examples/non_redacted_tcl/x27.tcl D examples/non_redacted_tcl/x28 D examples/non_redacted_tcl/x28.tcl D examples/non_redacted_tcl/x29 D examples/non_redacted_tcl/x29.tcl D examples/non_redacted_tcl/x30 D examples/non_redacted_tcl/x30.tcl D examples/non_redacted_tcl/x31 D examples/non_redacted_tcl/x31.tcl D examples/non_redacted_tcl/x33 D examples/non_redacted_tcl/x33.tcl D examples/non_redacted_tk/CMakeLists.txt D examples/non_redacted_tk/Makefile.examples.in D examples/non_redacted_tk/README.tkdemos D examples/non_redacted_tk/plgrid.in D examples/non_redacted_tk/plserver_runAllDemos.in D examples/non_redacted_tk/plserver_standard_examples.in D examples/non_redacted_tk/runAllDemos.tcl D examples/non_redacted_tk/runExtendedDemos.tcl D examples/non_redacted_tk/tk01.in D examples/non_redacted_tk/tk02.in D examples/non_redacted_tk/tk03.in D examples/non_redacted_tk/tk04.in D examples/non_redacted_tk/tkdemos.tcl D examples/non_redacted_tk/wish_runAllDemos.in D examples/non_redacted_tk/wish_standard_examples.in D examples/non_redacted_tk/xtk01.c D examples/non_redacted_tk/xtk02.c D examples/non_redacted_tk/xtk04.c M plplot_test/CMakeLists.txt M plplot_test/plplot-test-interactive.sh.in M plplot_test/plplot-test.sh.in M src/CMakeLists.txt commit bc7df37f6881260bef4f4391862d343181a5d066 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Sep 3 15:16:09 2017 -0700 Fortran cruft removal As of PLplot-5.12.0, a new Fortran binding was implemented using the powerful capabilities of the Fortran 2003 iso_c_binding module which was the replacement for the old binding that was implemented using a combination of Fortran and C code. The new binding is much simpler, more consistent, and more standards-compliant than the old binding and has some powerful new features (e.g., both single and double precisions Fortran floating-point arguments are accepted). Therefore, the new binding is necessarily backwards incompatible with the old binding. For PLplot-5.12.0 we implemented the CMake option -DPL_DEPRECATED_fortran=ON to provide temporary deprecated access to the old Fortran binding, and that form of backwards compatibility continued to be provided for the PLplot-5.13.0 release. However, it appears our users are generally satisfied with the new binding, and we no longer want to maintain or test that old binding. So for this commit the old binding has been completely removed from our source tree. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by building the test_diff_psc target. M README.release M bindings/CMakeLists.txt D bindings/old_fortran/CMakeLists.txt D bindings/old_fortran/global_defines.sed D bindings/old_fortran/plparseopts.f90 D bindings/old_fortran/plplot_parameters.inc D bindings/old_fortran/plplot_types.f90.in D bindings/old_fortran/plplotfortran.def D bindings/old_fortran/plplotfortran_ifort.def D bindings/old_fortran/plplotfortran_mingw.def D bindings/old_fortran/plstubs.h D bindings/old_fortran/readme_f95.txt D bindings/old_fortran/sc3d.c D bindings/old_fortran/sccont.c D bindings/old_fortran/scstubs.c D bindings/old_fortran/sfstubs.inc D bindings/old_fortran/sfstubsfortran.f90 D bindings/old_fortran/strutil.f90 M cmake/modules/fortran.cmake M cmake/modules/plplot_version.cmake M doc/Doxyfile.in M examples/CMakeLists.txt D examples/old_fortran/CMakeLists.txt D examples/old_fortran/Makefile.examples.in D examples/old_fortran/plfortrandemolib.f90 D examples/old_fortran/plfortrandemos.inc.in D examples/old_fortran/test_plfortrandemolib.f90 D examples/old_fortran/x00f.f90 D examples/old_fortran/x01f.f90 D examples/old_fortran/x02f.f90 D examples/old_fortran/x03f.f90 D examples/old_fortran/x04f.f90 D examples/old_fortran/x05f.f90 D examples/old_fortran/x06f.f90 D examples/old_fortran/x07f.f90 D examples/old_fortran/x08f.f90 D examples/old_fortran/x09f.f90 D examples/old_fortran/x10f.f90 D examples/old_fortran/x11f.f90 D examples/old_fortran/x12f.f90 D examples/old_fortran/x13f.f90 D examples/old_fortran/x14f.f90 D examples/old_fortran/x15f.f90 D examples/old_fortran/x16af.f90 D examples/old_fortran/x16f.f90 D examples/old_fortran/x17f.f90 D examples/old_fortran/x18f.f90 D examples/old_fortran/x19f.f90 D examples/old_fortran/x20f.f90 D examples/old_fortran/x21f.f90 D examples/old_fortran/x22f.f90 D examples/old_fortran/x23f.f90 D examples/old_fortran/x24f.f90 D examples/old_fortran/x25f.f90 D examples/old_fortran/x26f.f90 D examples/old_fortran/x27f.f90 D examples/old_fortran/x28f.f90 D examples/old_fortran/x29f.f90 D examples/old_fortran/x30f.f90 D examples/old_fortran/x31f.f90 D examples/old_fortran/x33f.f90 M plplot_test/CMakeLists.txt M plplot_test/plplot-test.sh.in M scripts/style_source.sh commit 259a7d4a90d63a39c0f7fd95a37ef9f163e73be6 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Sep 2 19:09:57 2017 -0700 Update script to remove trailing whitespace Files in the debian directory are no longer ignored (since this directory does not exist any more), and all *.pyc files are now ignored. This change was motivated by an attempt to remove trailing whitespace from bindings/python/Plframe.pyc. M scripts/remove_trailing_whitespace.sh commit b3ef719f9ee5a763baa4705104a97c95c178afd3 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Sep 2 19:00:29 2017 -0700 Build system: rewrite logic for determining PYQT_SIP_DIR and PYQT_SIP_FLAGS For pyqt4 the pyqtconfig module useful for determining PYQT_SIP_DIR and PYQT_SIP_FLAGS has been deprecated and has therefore already completely disappeared from some software platforms (e.g., MinGW-w64/MSYS2). Therefore, in this commit we have replaced that approach with an approach very similar to what we currently use for pyqt5 (where the pyqtconfig module has never been available). PYQT_SIP_FLAGS is easy to determine without the pyqtconfig module, but determination of PYQT_SIP_DIR, the location where the PyQT sip files are located is not completely straightforward. For the Debian-based Linux platforms and rpm-based Linux platforms accessible with rpm.pbone, Cygwin, and MinGW-w64/MSYS2, we feel we have the correct HINTS in place to find this directory. But for other platforms where this might be an issue, the user is invited to install a system package with the needed pyqt-related sip files, but if those have already been installed, then they are invited to work around the problem by specifying the correct PYQT_SIP_DIR to find those files, and communicating with us to update our HINTS appropriately for their platform. Since the pyqt[45] logic is now so similar, we have reorganized the CMake code to treat those two cases as much as possible with the same code. We have also taken the opportunity to style this CMake code using emacs cmake mode. That styling included replacing all tabbed indentation by spaced indentation. (I have just discovered with that emacs mode that you can do such replacement by replacing all tabs with large numbers of spaces, then the correct spaced indentation will be used if you subsequently style all lines by selecting all lines of the file and hitting ctrl-alt-backslash.) Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) using the 4 combinations of the cmake options DFORCE_PYTHON2=OFF/ON -DPLPLOT_USE_QT5=OFF/ON. In all cases, the PyQt sip directory (and sip flags) were found without issues, and building the appropriate test_pyqt[45]_example target for each case proceeded without issues other than pyqt5_example sometimes segfaulted at the end (a known, long-standing issue with Qt5). Additional testing of this new logic is requested on all accessible platforms. M cmake/modules/qt.cmake commit 1b93965d437f3c63517cb0ac712482bcda8bf012 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Aug 27 18:04:41 2017 -0700 pytkdemo: import and reload improvements * For both pytkdemo and its Plframe.py dependency, I replaced all non-namespaced imports of PLplot modules with the namespaced version. This change removes the double import (one namespaced and one not) for Plframe so likely solves the corruption of bindings/python/Plframe.pyc by a Python race condition that according to a Python developer had been solved for Python3 (which my results confirm since I never got corruption in that case), but likely not for Python2 (as my on-going corruption results before the present release for this Python version also confirm). * I improved the pytkdemo logic to work around the different ways to access the reload function in Python for the three cases if version < 3.0.0:, elif version < 3.4.0:, else: Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux Debian Jessie by building the test_pytkdemo target (both with and without -DFORCE_PYTHON2=ON) and clicking on all examples as well as the "clear", "clone", "reload", and "dismiss" buttons without issues. M bindings/python/Plframe.py M examples/python/pytkdemo commit 9cc0e68cd8a629e25cbbdb7629499874cf29e2b6 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Aug 27 15:00:21 2017 -0700 Remove trailing whitespace from ChangeLog.release M ChangeLog.release commit e3202104b66994c7dc7693c06b5ac125e55eaa0a Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Aug 27 14:36:11 2017 -0700 Build system: Improve user control of Python version The build system now takes the following steps to search for a suitable Python version. * The build system searches for the PLPLOT_PYTHON_EXACT_VERSION version of Python where PLPLOT_PYTHON_EXACT_VERSION is specified by the user. If this string is not specified by the user it defaults to "", and this exact search therefore always fails in this case. * If that first exact search is a failure and the option FORCE_PYTHON2 is not ON, the build system searches for PYTHON 3. * If neither of the above two searches is a success, then the build system searches for Python 2. Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux (Debian Jessie) by repeated fresh configurations of PLplot with -DPLPLOT_PYTHON_EXACT_VERSION=<Version> strings or -DFORCE_PYTHON2=ON specified. <Version> strings such as "", "whatever", and "1.0.0" found nothing so Python version 3.4.2 was found according to the above logic. <Version> strings such as "2.0.0" found unsuitable 2.7.9 so that exact match failed. However, those find values were cached so the subsequent logic above found 2.7.9. <Version> strings such as "3.9.9" found unsuitable 3.4.3 so that exact match failed. However, those find values were cached so the subsequent logic above found 3.4.3. The <Version> string "2.7.9" immediately found suitable 2.7.9. The <Version> string "3.4.3" immediately found suitable 3.4.3. -DFORCE_PYTHON2=ON immediately found 2.7.9. All of these Python version finding results are as expected. M README.release M cmake/modules/python.cmake commit cf7faa2c13a0478487ad95c9eac021279a04021a Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sun Aug 27 00:10:41 2017 -0700 Build system: Improve version check for wxwidgets I replaced our brute-force version check (which did not deal well with the situation where multiple versions of wxwidgets were available) with the native version check capability of the find module for wxWidgets. A byproduct of this change is the wxwidgets version that is found is automatically printed out. M cmake/modules/wxwidgets.cmake commit 790a0c66f9bbc805dbabeda05bb3d933e7ce57e8 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Aug 26 15:46:51 2017 -0700 Correct the URL (https: protocol rather than http:) for Testing reports M README.release commit dde43575033e646015c2bf083f54c8972593031b Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Aug 26 14:59:18 2017 -0700 Create new (preliminary) version of release notes for the next release M README.release commit d3f8530c912e3c03fea786aed978448e4e8356b0 Author: Alan W. Irwin <airwin@users.sourceforge.net> Date: Sat Aug 26 14:49:03 2017 -0700 Tweak README.Release_Manager_Cookbook These tweaks concern improved instructions/fixes that occurred in the last stages of the 5.13.0 release. M README.Release_Manager_Cookbook