From: Arjen M. <arj...@de...> - 2013-06-24 12:43:00
|
Hello, last week on the comp.lang.fortran newsgroup, someone asked about graphical libraries that can be used from Fortran programs. My suggestion for PLplot led to the following answer from Clive Page: ------ Thanks, Arjen. I'm sure it's easy when you know how, but I find the documentation more than a little confusing, so I don't know how. Indeed after some attempts in the past, I have just given up, and continued with PGPLOT (which is also a brute to build, but at least I know how to overcome its foibles) or DISLIN, which comes with pre-built libraries and is very simple to install and use on both Windows and Linux. For a start the plplot source code seems to come only in a gzipped tar file. Now I know perfectly well how to deal with them on Unix or Linux, but haven't the faintest idea on Windows. My MinGW system works for me when I use gfortran (and g95) but doesn't seem to support tar or gzip out of the box. Then I looked at this page: http://www.miscdebris.net/plplot_wiki/index.php?title=Configure_PLplot_for_MinGW/CLI which mentions the wxWidgets driver. Does one need this for plplot - I've no idea and can find no explanation of what it does. Maybe only for on-screen graphics - but that's a highly desirable feature of a graphics package. Then there is some cryptic stuff about not using the MSYS command window. I vaguely remember having to set up and use an MSYS window on another Windows system long ago, but haven't any idea why I had to do that, and it was painful enough I don't want to repeat the experience. There are also many mentions of Win32 - will this all work on a 64-bit version of Windows? Again I have no idea, can only guess. I like to suggest that if the enthusiasts for plplot want to make it the graphics package of choice for Fortran users on Windows then they should create a pre-built library that one can simply download. Having to build the package from source is a serious obstacle to adoption. Or - and this is very much a second best - provide really simple and comprehensive instructions of all the steps the ordinary Windows user needs to perform to download, unzip, untar, build, and install the PLPLOT library. Including all the tricky bits like getting the environment variables and PATH set up right. ------ We have discussed the possibility of binary distributions in the past, but there never was an opportunity as far as I remember to really do something about it. CMake does come with CPack and that might just be the vehicle we could use for this. I think it will fit in smoothly with Alan's work on building the external libraries from within the PLplot build system. Of course there are many problems to tackle, besides the technical ones: - What kind of builds would we provide? If only: single or double precision, what drivers, what languages, etc. - How to distribute the packaged versions? Just put them next to the tarballs with the sources? Who is going to make them? I would like to examine the questions Clive raised - just a minimal package so that he can experiment with PLplot and we with the question of packaging. Would this indeed be useful or is it a bad idea from the very start? Mind you: I do not intend to offer packages for all the configuration options PLplot supports. Merely a practical subset so that people can easily get started. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-06-24 19:12:03
|
Hi Arjen: This is an extremely interesting topic for me. More below in context. On 2013-06-24 14:42+0200 Arjen Markus wrote: > We have discussed the possibility of binary distributions in the past, > but there never was an opportunity as far as I remember to really do > something about it. CMake does come with CPack and that might just be > the vehicle we could use for this. As a proof of concept we have successfully created local binary distributions of PLplot in the past using the CPack facilities. As I recall, there is some trick to it because we use absolute rather than relative installation paths so if you cannot find that trick in our mailing list archives you might need to ask on the CMake list or look into the CMake wiki to figure out what to do for absolute installation paths. But there should be no fundamental technical roadblocks to creating binary distributions of PLplot right now using the existing CPack facilities. > > I think it will fit in smoothly with Alan's work on building the > external libraries from within the PLplot build system. Yes it would. > > Of course there are many problems to tackle, besides the technical > ones: > - What kind of builds would we provide? If only: single or double > precision, what drivers, what languages, etc. I have thought about this question for build_projects. What I will probably configure there is a plplot-lite build (essentially no dependencies at all other than shapelib and qhull) but which includes the C++, Fortran 95, and Ada bindings (i.e., all languages supported by MinGW out of the box) and a fully configured plplot build that includes dependencies (and the appropriate builds) of essentially everything (e.g., Qt4, pango/cairo, wxwidgets, Tcl [but not Tk for technical reasons we have discussed before]) that we have access to in the Linux version of PLplot. This one would probably require several hours to build. The only point of plplot-lite is quick build times, and if we decide to distribute a binary version of PLplot, I think the complete version of PLplot (the double precision form including most device drivers and bindings as is distributed on Linux) is what we would want to distribute. > - How to distribute the packaged versions? Just put them next to > the tarballs with the sources? Yes. That is what other projects do (e.g., MinGW) at SourceForge. > I would like to examine the questions Clive raised - just a minimal > package so that he can experiment with PLplot and we with the > question of packaging. Would this indeed be useful or is it a bad idea > from the very start? > There are other issues not covered above which should be considered. Most of them are straightforward, but I think one of them (security concerns) is tricky. * Our source code distribution obligations under open-source licenses. Generally according to these licenses, we would have to distribute not only our binary version, but _all_ the source code that went into that. Note, this includes the source code of the dependent libraries that we build as part of our distribution such as Qt4, pango/cairo, wxwidgets, etc. Large binary distributions are completely permitted by SourceForge (planetary and time ephemerides distributed by my timeephem project currently consume more than a Gigabyte of file space). So technically, all that would be required is for the build_projects project to preserve and distribute the source code that it downloads. So it should be entirely straightforward to fulfill these obligations. * Shared libraries versus static. I think static libraries are a no-brainer on Windows despite the size implications. I think we want static PLplot libraries and static libraries which PLplot depends on in our binary distribution so there is no chance of other downloaded versions of shared libraries interfering with the PLplot binary distribution results. I haven't implemented this yet, but propagating the -DBUILD_SHARED_LIBRARIES=OFF cmake command line option to all built projects is completely straightforward for build_projects. * Static run time. I think we want this as well if possible. I believe this topic has come up recently here, but I don't recall the conclusion about whether this is feasible. * Security concerns. Every large open-source project out there (e.g., Fedora, Debian, Ubuntu, Linux kernel, and SourceForge itself) have had completely successful security attacks on them in the last decade where the attacker ended up completely "owning" the system from hours to days. To deal with the fallout from these attacks, these big projects had to do complete forensic analysis of their attacked systems and were sometimes down for months because of the time that audit required. So security is a major and on-going issue for any binary distributor of open-source software because the downsides of a security issue are pretty big. For example, you have to ask yourself, what would it do to PLplot's reputation, if some home or company computer where you were creating the binary distribution of PLplot had been silently compromised so that our binary distribution of PLplot propagated an attack vector (virus or whatever) to all our Windows users? Despite the above successful attacks on Linux-related sites, Linux still has a better reputation for security than Windows so probably if we wanted to do a binary distribution, it would be best to generate it on a Linux/Wine platform where Wine was built on Linux from source and only minimal components of the build platform (essentially just MinGW and MSYS) were downloaded binaries. That implies everything else (such as CMake itself, Python, etc.) would need to be built from source, but that is certainly doable with the build_projects approach. So my conclusion is that build_projects could be the core of something much bigger, a Windows binary distribution of PLplot and all its dependencies (or thinking really big here, a full blown binary distribution of most free software). However, such binary distributions are not completely straightforward (security is the biggest issue in my opinion) so for now I think it is _much_ simpler to distribute build_projects and let users build a complete binary version of PLplot for themselves from that following a very simple cookbook. For example, I am thinking a 10-minute build of a minimal PLplot using build_projects might satisfy Clive's current needs. By the way, build_projects is getting close to being ready for someone like Clive to do a minimal PLplot build, but there are still some issues. For example, I still need to write some really simple documentation that some guy like Clive can just follow. Also, there are some generator issues I am currently investigating. For example, the "Ninja" generator looks extremely promising, but I had to abandon it for now (except for occasional specific diagnostic use) because it doesn't (currently) support Fortran. I have discovered that the "NMake Makefiles JOM" generator builds pure C projects like shapelib and ndiff without issues, but I have yet to investigate whether that generator can build a minimal PLplot that includes, e.g., C++, Fortran, and Ada. And I am currently investigating a build-system bug that showed up for "MinGW Makefiles" as a result of a recent change I did. But "MSYS Makefiles" on Wine and "Unix Makefiles" on Linux are currently working for a minimal PLplot build, and I am pretty sure the issues I mentioned above for that build will be sorted out within the next several days. But if Clive or other Windows users have more complex PLplot needs including Qt4, pango/cairo, and wxwidgets, then it may be a month or so before build_projects is ready for such needs. 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 __________________________ |
From: Andrew R. <and...@us...> - 2013-06-24 19:40:17
|
I agree with Alan's caution over this, however if we _can_ manage a windows binary distribution then that would immeasurably widen the appeal of plplot. The fact is that plplot is a complex beast to build given the dependencies and Windows users tend to be far less used to this kind of thing than Linux users. Even on Linux, the fact that we have packages in the major distributions has certainly widened our user base. Alan's work looks like a good step in the right direction. Andrew On Monday 24 Jun 2013 12:11:52 Alan W. Irwin wrote: > Hi Arjen: > > This is an extremely interesting topic for me. More below in context. > > On 2013-06-24 14:42+0200 Arjen Markus wrote: > > We have discussed the possibility of binary distributions in the past, > > but there never was an opportunity as far as I remember to really do > > something about it. CMake does come with CPack and that might just be > > the vehicle we could use for this. > > As a proof of concept we have successfully created local binary > distributions of PLplot in the past using the CPack facilities. As I > recall, there is some trick to it because we use absolute rather than > relative installation paths so if you cannot find that trick in our > mailing list archives you might need to ask on the CMake list or look > into the CMake wiki to figure out what to do for absolute installation > paths. But there should be no fundamental technical roadblocks to > creating binary distributions of PLplot right now using the existing > CPack facilities. > > > I think it will fit in smoothly with Alan's work on building the > > external libraries from within the PLplot build system. > > Yes it would. > > > Of course there are many problems to tackle, besides the technical > > ones: > > - What kind of builds would we provide? If only: single or double > > > > precision, what drivers, what languages, etc. > > I have thought about this question for build_projects. What I > will probably configure there is a plplot-lite build (essentially no > dependencies at all other than shapelib and qhull) but which includes > the C++, Fortran 95, and Ada bindings (i.e., all languages supported > by MinGW out of the box) > and a fully configured plplot build that > includes dependencies (and the appropriate builds) of essentially > everything (e.g., Qt4, pango/cairo, wxwidgets, Tcl [but not Tk for > technical reasons we have discussed before]) that we have access to in > the Linux version of PLplot. This one would probably require several > hours to build. The only point of plplot-lite is quick build > times, and if we decide to distribute a binary version of PLplot, I > think the complete version of PLplot (the double precision form > including most device drivers and bindings as is distributed on Linux) > is what we would want to distribute. > > > - How to distribute the packaged versions? Just put them next to > > > > the tarballs with the sources? > > Yes. That is what other projects do (e.g., MinGW) at SourceForge. > > > I would like to examine the questions Clive raised - just a minimal > > package so that he can experiment with PLplot and we with the > > question of packaging. Would this indeed be useful or is it a bad idea > > from the very start? > > There are other issues not covered above which should be considered. > Most of them are straightforward, but I think one of them (security > concerns) is tricky. > > * Our source code distribution obligations under open-source licenses. > Generally according to these licenses, we would have to distribute not > only our binary version, but _all_ the source code that went into > that. Note, this includes the source code of the dependent libraries > that we build as part of our distribution such as Qt4, pango/cairo, > wxwidgets, etc. Large binary distributions are completely permitted > by SourceForge (planetary and time ephemerides distributed by my > timeephem project currently consume more than a Gigabyte of file > space). So technically, all that would be required is for the > build_projects project to preserve and distribute the source code that > it downloads. So it should be entirely straightforward to fulfill > these obligations. > > * Shared libraries versus static. I think static libraries are a > no-brainer on Windows despite the size implications. I think we want > static PLplot libraries and static libraries which PLplot depends on > in our binary distribution so there is no chance of other downloaded > versions of shared libraries interfering with the PLplot binary > distribution results. I haven't implemented this yet, but propagating > the -DBUILD_SHARED_LIBRARIES=OFF cmake command line option to all > built projects is completely straightforward for build_projects. > > * Static run time. I think we want this as well if possible. I > believe this topic has come up recently here, but I don't recall the > conclusion about whether this is feasible. > > * Security concerns. Every large open-source project out there (e.g., > Fedora, Debian, Ubuntu, Linux kernel, and SourceForge itself) have had > completely successful security attacks on them in the last decade > where the attacker ended up completely "owning" the system from hours > to days. To deal with the fallout from these attacks, these big > projects had to do complete forensic analysis of their attacked > systems and were sometimes down for months because of the time that > audit required. > > So security is a major and on-going issue for any binary distributor > of open-source software because the downsides of a security issue are > pretty big. For example, you have to ask yourself, what would it do to > PLplot's reputation, if some home or company computer where you were > creating the binary distribution of PLplot had been silently > compromised so that our binary distribution of PLplot propagated an > attack vector (virus or whatever) to all our Windows users? > > Despite the above successful attacks on Linux-related sites, Linux > still has a better reputation for security than Windows so probably if > we wanted to do a binary distribution, it would be best to generate it > on a Linux/Wine platform where Wine was built on Linux from source and > only minimal components of the build platform (essentially just MinGW > and MSYS) were downloaded binaries. That implies everything else (such > as CMake itself, Python, etc.) would need to be built from source, but > that is certainly doable with the build_projects approach. > > > So my conclusion is that build_projects could be the core of something > much bigger, a Windows binary distribution of PLplot and all its > dependencies (or thinking really big here, a full blown binary > distribution of most free software). However, such binary > distributions are not completely straightforward (security is the > biggest issue in my opinion) so for now I think it is _much_ simpler > to distribute build_projects and let users build a complete binary > version of PLplot for themselves from that following a very simple > cookbook. For example, I am thinking a 10-minute build of a minimal > PLplot using build_projects might satisfy Clive's current needs. > > By the way, build_projects is getting close to being ready for someone > like Clive to do a minimal PLplot build, but there are still some > issues. For example, I still need to write some really simple > documentation that some guy like Clive can just follow. Also, there > are some generator issues I am currently investigating. For example, > the "Ninja" generator looks extremely promising, but I had to abandon > it for now (except for occasional specific diagnostic use) because it > doesn't (currently) support Fortran. I have discovered that the "NMake > Makefiles JOM" generator builds pure C projects like shapelib and > ndiff without issues, but I have yet to investigate whether that > generator can build a minimal PLplot that includes, e.g., C++, > Fortran, and Ada. And I am currently investigating a build-system bug > that showed up for "MinGW Makefiles" as a result of a recent change I > did. > > But "MSYS Makefiles" on Wine and "Unix Makefiles" on Linux are > currently working for a minimal PLplot build, and I am pretty sure the > issues I mentioned above for that build will be sorted out within the > next several days. But if Clive or other Windows users have more > complex PLplot needs including Qt4, pango/cairo, and wxwidgets, then > it may be a month or so before build_projects is ready for such needs. > > 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 > __________________________ > > ---------------------------------------------------------------------------- > -- This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <arj...@de...> - 2013-06-25 07:53:18
|
On Mon, 24 Jun 2013 12:11:52 -0700 (PDT) "Alan W. Irwin" <ir...@be...> wrote: > Hi Arjen: > > This is an extremely interesting topic for me. More >below in context. > Hi Alan, Andrew, I have been experimenting a bit with CPack and I ran into a bunch of small problems but nothing that we should not be able to cure with a minimal amount of work. (The largest at the moment being that there is something wrong with my MinGW installation, which makes it impossible to run "make".) Paths are going to be important, as will the type of "installer" and setting the environment variables properly. Actually, nothing new under the sun. An absolute path as the install prefix is not acceptable, I am afraid: CPack creates a directory tree under the build directory that reflects exactly the directory of the installation. That means that it would attempt to create a subdirectory "c:\program files(x86)\plplot" under that directory and a colon is not allowed in a path. We can, however, easily set the prefix to something more palatable, like "plplot". It is minor issues like these that I have run into. Well, and the big one I mentioned above. I think - but that is just a guess based on some quick glances - that the NSIS installer option is the most attractive one from the point of view of Windows users/ developers. For the moment I will concentrate on the ZIP installer, however, as that is simpler to control. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-06-25 20:03:53
|
On 2013-06-25 09:52+0200 Arjen Markus wrote: > An absolute path as the install prefix is not acceptable, > I am afraid: CPack creates a directory tree under the > build directory that reflects exactly the directory of > the installation. That means that it would attempt to > create a subdirectory "c:\program files(x86)\plplot" under > that directory and a colon is not allowed in a path. I finally found the reference concerning absolute install locations. Please take a look at http://public.kitware.com/Bug/view.php?id=4993 and the solution mentioned there which is to set CPACK_SET_DESTDIR to ON. In fact the CPack part of our top-level CMakeLists.txt file already does that, and it turns out everything works fine on Linux. For example, cmake -DCMAKE_INSTALL_PREFIX=/home/software/plplot_svn/installcmake \ ../plplot_allura >& cmake.out make package >& package.out creates a binary distribution tarball for PLplot without errors. The first few files in that tarball are lrwxrwxrwx software/software 0 2013-06-25 11:42 plplot-5.9.9-Linux/home/software/plplot_svn/installcmake/lib/libqsastime.so -> libqsastime.so.0 -rw-r--r-- software/software 23607 2013-06-25 11:14 plplot-5.9.9-Linux/home/software/plplot_svn/installcmake/lib/libqsastime.so.0.0.1 -rw-r--r-- software/software 11227 2013-06-25 11:15 plplot-5.9.9-Linux/home/software/plplot_svn/installcmake/lib/python2.7/site-packages/plplot_widgetmodule.so -rw-r--r-- software/software 25133 2013-05-22 12:03 plplot-5.9.9-Linux/home/software/plplot_svn/installcmake/lib/python2.7/site-packages/plplot.py In other words, the CPack part of our top-level CMakeLists.txt file includes logic such that the result is the tarball is created with relative paths started by "plplot-5.9.9-Linux/${CMAKE_INSTALL_PREFIX}". After I realized that, I tried the experiment of specifying the null string for CMAKE_INSTALL_PREFIX. cmake -DCMAKE_INSTALL_PREFIX="" ../plplot_allura >& cmake.out make package >& package.out That also worked (after revision 12387), and the first few files in the tarball were lrwxrwxrwx software/software 0 2013-06-25 12:20 plplot-5.9.9-Linux/lib/libqsastime.so -> libqsastime.so.0 -rw-r--r-- software/software 23607 2013-06-25 12:19 plplot-5.9.9-Linux/lib/libqsastime.so.0.0.1 -rw-r--r-- software/software 11227 2013-06-25 12:20 plplot-5.9.9-Linux/lib/python2.7/site-packages/plplot_widgetmodule.so -rw-r--r-- software/software 25133 2013-05-22 12:03 plplot-5.9.9-Linux/lib/python2.7/site-packages/plplot.py So at least on Linux everything works as expected with "make package" for creating a binary tarball distribution of PLplot, and there is a way to completely remove the influence of CMAKE_INSTALL_PREFIX on the relative paths within the tarball. Looking at the CPack section of the top-level CMakeLists.txt file, I am pretty sure that "make package" should also just work to create a zip binary distribution of PLplot for the Windows case. Have you tried "make package"? Note that for the Windows zip case, the use of CMAKE_INSTALL_PREFIX may be quite different than the tarball case so it is probably best that you try various DCMAKE_INSTALL_PREFIX values to see which is best for the Windows zip case. I plan to try such experiments on Wine early next week. So please let me know your Windows results for "make package" by then to serve as a basis of comparison. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2013-06-26 06:45:07
|
Hi Alan, on MinGW the default value for CPACK_INSTALL_PREIX is now "C:/Program Files(x86)/plplot". It is the first part, "C:", that causes trouble. The trouble I had with MinGW/MSYS was rather strange - whenever I typed "make" in an MSYS-box, it ran the MicroSoft version of "make". When I typed "exit", it ran that make version again! Something was really upset, but after a reboot it all worked again. I changed the install type and the prefix and the zip-file was formed nicely. (Instead of "make package" I ran CPack directly, but the effect is the same.) What I want to do at this moment is see if the environment variables can be set in a convenient way. Regards, Arjen On Tue, 25 Jun 2013 13:03:45 -0700 (PDT) "Alan W. Irwin" <ir...@be...> wrote: > On 2013-06-25 09:52+0200 Arjen Markus wrote: > >> An absolute path as the install prefix is not >>acceptable, >> I am afraid: CPack creates a directory tree under the >> build directory that reflects exactly the directory of >> the installation. That means that it would attempt to >> create a subdirectory "c:\program files(x86)\plplot" >>under >> that directory and a colon is not allowed in a path. > > I finally found the reference concerning absolute >install locations. > Please take a look at >http://public.kitware.com/Bug/view.php?id=4993 > and the solution mentioned there which is to set >CPACK_SET_DESTDIR > to ON. > > In fact the CPack part of our top-level CMakeLists.txt >file already > does that, and it turns out everything works fine > on Linux. For example, > > cmake >-DCMAKE_INSTALL_PREFIX=/home/software/plplot_svn/installcmake >\ > ../plplot_allura >& cmake.out > make package >& package.out > > creates a binary distribution tarball for PLplot without >errors. The first few > files in that tarball are > > lrwxrwxrwx software/software 0 2013-06-25 11:42 >plplot-5.9.9-Linux/home/software/plplot_svn/installcmake/lib/libqsastime.so >-> libqsastime.so.0 > -rw-r--r-- software/software 23607 2013-06-25 11:14 >plplot-5.9.9-Linux/home/software/plplot_svn/installcmake/lib/libqsastime.so.0.0.1 > -rw-r--r-- software/software 11227 2013-06-25 11:15 >plplot-5.9.9-Linux/home/software/plplot_svn/installcmake/lib/python2.7/site-packages/plplot_widgetmodule.so > -rw-r--r-- software/software 25133 2013-05-22 12:03 >plplot-5.9.9-Linux/home/software/plplot_svn/installcmake/lib/python2.7/site-packages/plplot.py > > In other words, the CPack part of our top-level >CMakeLists.txt file > includes logic such that the result is the tarball is >created with > relative paths started by >"plplot-5.9.9-Linux/${CMAKE_INSTALL_PREFIX}". > > After I realized that, I tried the experiment of >specifying the null string for > CMAKE_INSTALL_PREFIX. > > cmake -DCMAKE_INSTALL_PREFIX="" ../plplot_allura >& >cmake.out > make package >& package.out > > That also worked (after revision 12387), and the first >few files in the tarball were > lrwxrwxrwx software/software 0 2013-06-25 12:20 >plplot-5.9.9-Linux/lib/libqsastime.so -> libqsastime.so.0 > -rw-r--r-- software/software 23607 2013-06-25 12:19 >plplot-5.9.9-Linux/lib/libqsastime.so.0.0.1 > -rw-r--r-- software/software 11227 2013-06-25 12:20 >plplot-5.9.9-Linux/lib/python2.7/site-packages/plplot_widgetmodule.so > -rw-r--r-- software/software 25133 2013-05-22 12:03 >plplot-5.9.9-Linux/lib/python2.7/site-packages/plplot.py > > So at least on Linux everything works as expected with >"make package" > for creating a binary tarball distribution of PLplot, >and there is > a way to completely remove the influence of >CMAKE_INSTALL_PREFIX on the > relative paths within the tarball. > > Looking at the CPack section of the top-level >CMakeLists.txt file, I > am pretty sure that "make package" should also just work >to create a zip > binary distribution of PLplot for the Windows case. > > Have you tried "make package"? Note that for the >Windows zip case, > the use of CMAKE_INSTALL_PREFIX may be quite different >than the > tarball case so it is probably best that you try various > DCMAKE_INSTALL_PREFIX values to see which is best for >the Windows zip > case. > > I plan to try such experiments on Wine early next week. > So please let > me know your Windows results for "make package" by then >to serve as a > basis of comparison. > > 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 > __________________________ > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2013-06-26 08:01:55
|
Hi Alan, I am almost there: small batch file to define a bunch of environment variables. There is one thing that I do not quite like: The colour map files need to be installed in "c:\program files (x86)\plplot\share\plplot5.9.9" This is slightly annoying because this requires administrator rights in some cases (Windows may be set to use a strict policy and I encounter more and more restrictions). It would be nice to be able to put the PLplot package anywhere. (By the looks of it, it is not difficult to do.) More on this later. Regards, Arjen On Wed, 26 Jun 2013 08:44:51 +0200 "Arjen Markus" <arj...@de...> wrote: > ... What I want to do > at this moment is see if the environment variables can > be set in a convenient way. > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Schwartz, S. J <s.s...@im...> - 2013-06-26 11:32:55
|
Alan, Arjen, et al., I have been following this thread, and the parallel ones re Cygwin build and also build_project, with some interest. We ship a binary Windows version of our QSAS software (which includes the Qt libraries and a somewhat stripped-down version of plplot which only drives our own version of the qt-widgets device). This seems to work fine. As I have succumbed to the corporate Windows pressure I no longer use linux so have spent more time exploring aspects of Windows builds. I'm a novice in Cygwin, mingw, and msys. QSAS builds under msys. We/I don't build Qt from source (but if Alan has a foolproof way to do that I'd consider having a go). So I use the last Qt4 binary system provided by Qt, namely 4.8.4. This was built against mingw 4.4, and there are various discussion-group posts suggesting that compiling against this binary Qt requires using the same version of mingw. Luckily (?) someone out there made a zipped file with mingw 4.4.0 available for precisely that reason. This I access via the msys layer (which is needed for some or other reason, rather than just building directly in mingw. I have noticed that other modules we use didn't interface correctly when built directly from mingw for probably subtle reasons, so I have stuck to always working in an msys window/environment). We don't use cmake (and have ceased using configure - preferring a relatively simple and transparent build shell-script. The script builds the necessary bits of plplot alongside other 3rd party modules and the rest of QSAS). I have tried to build a more complete plplot against this configuration, namely: Windows 7 Qt 4.8.4 binary Mingw 4.4.0 Msys (current version) Cmake 2.8.11 (windows) The build almost completes normally, but test-drv-info crashes dealing with the qt drivers. The windows crash report shows that the error occurred in libgcc_s_dw2-1.dll. Nonetheless everything appears to have been built and installs ok. The native plplot drivers (wingcc, ps,psc, svg) run fine. The Qt ones enjoy mixed success. Sometimes they crash in the same way, other times they run fine (small changes to the source files - looks like some memory issues). The qt ps and pdf files always generate a portrait page with the plot spilling off the right hand edge of the page or, if some appropriate combination of orientation options is given on the command line, shrunk and rotated and pushed to the top-right of the portrait page. I've not tried to install the extra bits to try to build other drivers such as wxWidgets, cairo, etc., and do not need them. To be honest, the bare wingcc and psc drivers are adequate for my testing needs, with my main work done via QSAS. [There is a separate notion here about what a "minimal binary plplot" distribution might contain, which risks everyone chipping in their one additional driver and binding until you get back to the full distribution :-)] I offer the above (a) in case it is helpful to anyone (b) to offer continued encouragement and (c) in case any of the above wrinkles ring a bell in someone's head and they have suggestions on how I might improve any aspect thereof. Best wishes Steve -------------------------------------------------------------------- Professor Steven J Schwartz Phone: +44 (0)207 594 7660 Head, Space & Atmospheric Physics Fax: +44 (0)207 594 7772 The Blackett Laboratory Email: s.s...@im... Imperial College London Office: Huxley 6M67A London SW7 2AZ, UK Web: www.sp.ph.ic.ac.uk/~sjs -------------------------------------------------------------------- |
From: Arjen M. <arj...@de...> - 2013-06-26 12:39:19
|
Hi Steven, interesting, my experience with Qt is very limited, but it definitely is something to keep in mind - as are your other experiences. Note, when I wrote "minimal distribution" I was thinking more along the lines of minimzing the amount of work to build the distribution. Besides drivers and languages one could also provide subpackages and other installation options. We have to be careful there too :). Regards, Arjen On Wed, 26 Jun 2013 11:32:28 +0000 "Schwartz, Steven J" <s.s...@im...> wrote: > Alan, Arjen, et al., > > I have been following this thread, and the parallel ones >re Cygwin build and also build_project, with some >interest. We ship a binary Windows version of our QSAS >software (which includes the Qt libraries and a somewhat >stripped-down version of plplot which only drives our own >version of the qt-widgets device). This seems to work >fine. As I have succumbed to the corporate Windows >pressure I no longer use linux so have spent more time >exploring aspects of Windows builds. I'm a novice in >Cygwin, mingw, and msys. > > QSAS builds under msys. We/I don't build Qt from source >(but if Alan has a foolproof way to do that I'd consider >having a go). So I use the last Qt4 binary system >provided by Qt, namely 4.8.4. This was built against >mingw 4.4, and there are various discussion-group posts >suggesting that compiling against this binary Qt requires >using the same version of mingw. Luckily (?) someone out >there made a zipped file with mingw 4.4.0 available for >precisely that reason. This I access via the msys layer >(which is needed for some or other reason, rather than >just building directly in mingw. I have noticed that >other modules we use didn't interface correctly when >built directly from mingw for probably subtle reasons, so >I have stuck to always working in an msys >window/environment). We don't use cmake (and have ceased >using configure - preferring a relatively simple and >transparent build shell-script. The script builds the >necessary bits of plplot alongside other 3rd party >modules and the rest of QSAS). > > I have tried to build a more complete plplot against >this configuration, namely: > > Windows 7 > Qt 4.8.4 binary > Mingw 4.4.0 > Msys (current version) > Cmake 2.8.11 (windows) > > The build almost completes normally, but test-drv-info >crashes dealing with the qt drivers. The windows crash >report shows that the error occurred in >libgcc_s_dw2-1.dll. Nonetheless everything appears to >have been built and installs ok. The native plplot >drivers (wingcc, ps,psc, svg) run fine. The Qt ones enjoy >mixed success. Sometimes they crash in the same way, >other times they run fine (small changes to the source >files - looks like some memory issues). The qt ps and pdf >files always generate a portrait page with the plot >spilling off the right hand edge of the page or, if some >appropriate combination of orientation options is given >on the command line, shrunk and rotated and pushed to the >top-right of the portrait page. I've not tried to install >the extra bits to try to build other drivers such as >wxWidgets, cairo, etc., and do not need them. To be >honest, the bare wingcc and psc drivers are adequate for >my testing needs, with my main work done via QSAS. [There >is a separate notion here about what a "minimal binary >plplot" distribution might contain, which risks everyone >chipping in their one additional driver and binding until >you get back to the full distribution :-)] > > I offer the above (a) in case it is helpful to anyone >(b) to offer continued encouragement and (c) in case any >of the above wrinkles ring a bell in someone's head and >they have suggestions on how I might improve any aspect >thereof. > > Best wishes > Steve > > -------------------------------------------------------------------- > Professor Steven J Schwartz Phone: +44 (0)207 >594 7660 > Head, Space & Atmospheric Physics Fax: +44 (0)207 >594 7772 > The Blackett Laboratory Email: > s.s...@im... > Imperial College London Office: Huxley 6M67A > London SW7 2AZ, UK Web: > www.sp.ph.ic.ac.uk/~sjs > -------------------------------------------------------------------- > > > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Schwartz, S. J <s.s...@im...> - 2013-06-26 13:49:03
|
Arjen, Arjen Markus wrote on 2013-06-26: ---------------- > Note, when I wrote "minimal distribution" I was thinking more along > the lines of minimzing the amount of work to build the distribution. Understood, but these two are not completely unrelated concepts, or at least they minimise different burdens on the user. I think it would be straightforward to create a minimal version of plplot that could be easily built by anyone with a gcc compiler. It would drive limited devices, e.g., ps/psc, svg, wingcc (windows) and xwin (*nix). It would have limited bindings (c, c++, fortran). And it would build from a single flat src directory and a single relatively short Makefile (probably different for each target platform to cope with pathnames and such) with a few editable lines at the top - or as we do for QSAS an editable shell script that sets up environment variables and calls make. This minimises the work in getting something up and running. You have a better feel than I do concerning the plplot user community to gauge what percentage of your users might have been happy to start this way. Deconstructing the full cmake plplot distribution by then, say, adding separate bundles to add other bindings or devices may or may not make sense depending on the user community (i.e. whether one or two of these would reach a large fraction of the community or enable the plplot community to grow faster). This is a tradeoff between user effort and development effort, of course. Cmake, configure, scons and such are designed to keep a single development tree to ease maintenance, avoid duplication, and automagically solve platform/operating system quirks. In my experience, when they work, they're great; when they don't, many end-users will give up. Binary distributions are great for many end-users because they run out of the box (assuming they run - otherwise again end-users will give up). My impression is that the most difficult binaries are in the *nix world. It seems easier to create windows and mac binaries that will run without being too fussy about the version of everything else that is installed, but I have less experience in compiling against distributed 3rd party binary libraries which is what any plplot user would need to do. I wonder if a fairly drastic re-write of the windows (and other?) build/installation instructions for plplot would have been sufficient to help the original poster - Clive Page - make progress. In my experience, those instructions need to include step-by-step guidance about installing any other packages (cmake, mingw, msys, qt, ...) as well as how to build plplot. It should also give guidance about essential (e.g., gcc, say) vs optional (qt, wxWidgets, ...) requirements. Getting to the point where the plplot equivalent of "Hello world" compiles and runs provides an enormous encouragement to the new user. You may recall some time ago I suggested an example zero which would take the user through the steps to compile and run their own first plplot program, as opposed to the multitude of (very fine and comprehensive) plplot examples that get built by including special plcdemos.h headers and via the cmake build of all of plplot. There is such an example (x00) but not, as far as I can see, instructions about how a user can copy that to their own directory and compile it. Best wishes Steve -------------------------------------------------------------------- Professor Steven J Schwartz Phone: +44 (0)207 594 7660 Head, Space & Atmospheric Physics Fax: +44 (0)207 594 7772 The Blackett Laboratory Email: s.s...@im... Imperial College London Office: Huxley 6M67A London SW7 2AZ, UK Web: www.sp.ph.ic.ac.uk/~sjs -------------------------------------------------------------------- |
From: Alan W. I. <ir...@be...> - 2013-06-26 18:55:00
|
Hi Steve: On 2013-06-26 13:48-0000 Schwartz, Steven J wrote: > My impression is that the most difficult binaries are in the *nix world. It seems easier to create windows and mac binaries that will run without being too fussy about the version of everything else that is installed, but I have less experience in compiling against distributed 3rd party binary libraries which is what any plplot user would need to do. For Linux there has been a huge effort concerning soname conventions and backwards-compatible API over the last 10 years. So, for example, the occurrences of API breakage that has affected the PLplot build on Linux have been quite minimal. I assume the Windows libraries implemented by Microsoft are just as good as the Linux libraries in this respect. But a major problem for the Windows platform is it does not include the free libraries. For those, there is currently a "wild west" atmosphere so my understanding is Windows users of free software often end up with multiple incompatible versions of free libraries installed and a resulting "dll hell". The obvious answer to this issue is distributions of free software for the Windows platform with a guaranteed coherent ABI/API. The Cygwin distribution is the only one of such distributions that are available currently. In the future, the build_projects project, the jhbuild project (currently used to build GTK libraries), and/or the emerge project (currently used to build Qt4 and KDE) may be the core of additional Windows distributions of free software to provide Cygwin with some much-needed competition. Although I am obviously aware of the huge binary distribution potential for build_projects, I intend for now to mostly ignore that potential and concentrate almost exclusively on expanding build_projects from the current proof-of-concept stage to a fairly powerful build script that satisfies all my personal PLplot, ephcom, te_gen, and FreeEOS build and test needs on the Wine version of Windows. I emphasize that although build_projects is configured with CMake, the actual builds of the "external" projects that occur with this approach are all configured by CMake's ExternalProject_Add command. That command allows the use of any build system (e.g., CMake-based, autotools-based, or even Make-based) for the external project being built. For example, build_projects right now builds CMake-based shapelib and autotools-based wxwidgets on all platforms. Thus, others such as the QSAS team are certainly welcome to test this build script on any platform and add their own build configurations (which should be pretty trivial if you follow, say, the shapelib template) for software that interests them. 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 __________________________ |