On 2019-09-15 15:35-0700 Alan W. Irwin wrote:
Hi Takeshi:
[...]
I would appreciate you testing that result [plplot-5.15.0-34-g6b47c717e] for the test_d project (to make sure my further one-line change I committed beyond what you have tested already did not screw anything up) and also (if that test is a success) the plplot project itself.
For the others here I subsequently contacted Takeshi (and Arjen for the MSYS2 case) off list to put those tests on hold because I wanted to fix some additional issues I discovered when I attempted to comprehensively test ldc2 and dmd on Linux for a PLplot with all possible Linux components configured (as opposed to the good comprehensive tests results on my Linux platform that I get for a PLplot where only the C and D components were configured). The rest of this post is a status report on the remaining D build-system issues for a fully configured PLplot on Linux. I solved one of the issues (where Qt5 was polluting the D builds in the static case with the -fPIC compile option which ldc2 did not understand) by using the target_link_libraries PRIVATE option for the static library build. But the other issue (where our various thread library needs are met by the -pthread *compiler* option used for linking which neither dmd nor ldc2 understands) has proved much more difficult to solve (even though it is extremely easy to solve the issue by hand) *within the current constraints imposed by CMake*. For those interested, I have just posted a detailed report about this CMake-based build-system limitation and a possible feature request to solve it at <https://cmake.org/pipermail/cmake-developers/2019-September/031239.html>. As part of writing up that post today, I thought up a workaround for the issue that is a bit messy (since part of the workaround requires an extra library called PLPLOT::plplot_nothread to be built that is exactly the same as PLPLOT::plplot except for its modified INTERFACE_LINK_LIBRARIES property), but I think it will work until the day (if it ever comes) when the CMake developers decide to implement the above possible feature request. In sum, at least I finally have a plan to work around this issue, and (because a fair amount of build-system changes will be required) I hope to implement that plan (unless the CMake developers advise me of a simpler way to do the same thing) by (very roughly) the end of this week. Furthermore, the hold on non-Linux platform testing of D language support should continue for both Takeshi and Arjen until I demonstrate that the three D compilers all pass comprehensive testing of a fully configured PLplot on my platform. So until then... Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
