On 2015-05-25 17:29-0000 Arjen Markus wrote: > An issue related to the use of C++ that has not been raised yet, but which surfaced recently in my comprehensive testing efforts is the fact that linking a C++ program requires a C++-enabled linker. Thus introducing C++ as the language in which PLplot is to be implemented would complicate the use of static builds. That may not be the most common option nowadays, but I think we need to take a conscious decision: do we want to continue to support static builds or not? One pro for static builds is that they make deployment, especially of binary-only distributions much easier (and safer).
Hi Arjen: Yes, I think we should keep supporting static builds which work virtually perfectly now with our CMake-based build systems for the build of PLplot from source and the build of the installed examples. I assume what you mean by a C++-enabled linker is that extra libraries have to be linked in for that case. Our CMake build handles this situation with ease both for the core build and installed examples build. So static linking is already completely supported in that case. Of course, there is currently a limitation on our traditional (Makefile + pkg-config) build for e.g., Fortran examples where pkg-config does not automatically know the name/location of the special C++ library that needs to be linked in for a given C++ compiler so the user would have to add that link himself to the pkg-config results to successfully build the Fortran examples using our traditional build system for the installed examples. Currently this problem occurs if C++ code is included in libplplot from our C++ device drivers, psttf, qt, and wxwidgets. But that is a very common case (or should be) to have those device drivers enabled so if we adopt C++ for the core library this limitation in our traditional build will essentially just stay the same in most cases. So I don't see this limitation of our traditional build system for the installed examples as a big concern with switching our core library to C++ in all cases. Don't get me wrong, I would like this limitation to be resolved so that our traditional build of the installed examples works as well as the CMake build of those. When discussing this with Andrew I mentioned one possibility for implementing a fix for this issue, but that is a lot of work which I am going to leave to others if they want to make our Makefile+pkg-config approach as high quality as the CMake-based one for building our installed examples. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
