From: Alan W. I. <ir...@be...> - 2006-12-14 23:42:30
|
To Werner and Arjen: I hope this is a good time for one of you to start moving ahead on the small project of creating a binary release of PLplot for windows using cpack. I believe when we discussed this before, we were all in agreement this would be a good thing to do since, for example, major SF projects that have a windows port almost always include a windows binary version. I bring it up again now because (a) you are mostly done with the higher priority work of making sure all the PLplot features work properly on windows, and (b) there has just now been a request for such a binary release of PLplot for windows on the PDL list. In response to this request, it would be nice to bring out a binary release of PLplot for windows a few days after the scheduled source release in January (and after every source release thereafter), and from my experiments today I think only a small amount of additional debugging work should be required to make that happen. Assuming you want to go ahead with a binary release of PLplot for windows on that sort of time scale, then you should note we already use cpack to provide our source release of PLplot --- see the cpack-related items at the end of the top-level CMakeLists.txt file. These create a target called "package_source" which invokes cpack to pack everything in the source directory into a tarball. That target works well on Linux (in fact, we use it to create our source release tarball in scripts/make_tarball.sh), and you should also confirm it works well on windows. Similarly, a target called "package" is automatically created by our use of "include(CPack)" in our top-level CMakeLists.txt file. That target is supposed to invoke cpack to pack everything in the install tree into a tarball. Just now I tried make package but that yields an empty result for PLplot (with no error message). For CMake itself, that command indeed produces a tarball of the cmake install tree so that target should work similarly for us. I don't know what the PLplot problem with the "package" target is, but I assume intercomparison of our top-level CMakeLists.txt file with that of the cmake project and some experimentation should be able to sort out this PLplot issue. There is also some rudimentary documentation of cpack in (http://www.cmake.org/Wiki/CMake:Packaging_With_CPack) which might be of some help to you. If one of you would like to take on this small debugging project, that would be great since a binary release of PLplot for windows users would apparently be of some help to those users (especially Perl and Python users who ordinarily don't require a compiler). 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2006-12-15 08:57:07
|
Hi Alan, I'll have a look into this topic. Ideally we should provide two packages, one with Visual Studio C++ 6.0 libraries and one with MinGW libraries. Python and so on, can use both or at least one of these packages. I'm not aware of projects which would depend on Borland libraries and so on. Borland/Watcom users should compile plplot on their on. We would need VC++ 6.0 binaries, since all later VC++ can use them, but obviously if I make the binary with VC++ 2005 not many can use it than :). Since I have no access to VC++ 6.0, it would be perfect, if Arjen could provide this package. I intend to provide the mingw package than. If we sorted out how cpack can do this automatically this should be not much a problem. Problematic in any case will be how we add the additional libraries? Freetype, qhull, cd, agg are static (at least for vc++ 6.0) so no problem here, but wxWidgets can be made static and gd must be provided as dll. So this needs some research. Regards, Werner Alan W. Irwin wrote: > To Werner and Arjen: > > I hope this is a good time for one of you to start moving ahead on the small > project of creating a binary release of PLplot for windows using cpack. I > believe when we discussed this before, we were all in agreement this would > be a good thing to do since, for example, major SF projects that have a > windows port almost always include a windows binary version. I bring it up > again now because (a) you are mostly done with the higher priority work of > making sure all the PLplot features work properly on windows, and (b) there > has just now been a request for such a binary release of PLplot for windows > on the PDL list. In response to this request, it would be nice to bring out > a binary release of PLplot for windows a few days after the scheduled source > release in January (and after every source release thereafter), and from my > experiments today I think only a small amount of additional debugging work > should be required to make that happen. > > Assuming you want to go ahead with a binary release of PLplot for windows on > that sort of time scale, then you should note we already use cpack to > provide our source release of PLplot --- see the cpack-related items at the > end of the top-level CMakeLists.txt file. These create a target called > "package_source" which invokes cpack to pack everything in the source > directory into a tarball. That target works well on Linux (in fact, we use > it to create our source release tarball in scripts/make_tarball.sh), and you > should also confirm it works well on windows. > > Similarly, a target called "package" is automatically created by our use of > "include(CPack)" in our top-level CMakeLists.txt file. That target is > supposed to invoke cpack to pack everything in the install tree into a > tarball. Just now I tried > > make package > > but that yields an empty result for PLplot (with no error message). For > CMake itself, that command indeed produces a tarball of the cmake install > tree so that target should work similarly for us. I don't know what the > PLplot problem with the "package" target is, but I assume intercomparison of > our top-level CMakeLists.txt file with that of the cmake project and some > experimentation should be able to sort out this PLplot issue. There is also > some rudimentary documentation of cpack in > (http://www.cmake.org/Wiki/CMake:Packaging_With_CPack) which might be of > some help to you. > > If one of you would like to take on this small debugging project, that would > be great since a binary release of PLplot for windows users would apparently > be of some help to those users (especially Perl and Python users who > ordinarily don't require a compiler). > > Alan > __________________________ > Alan W. Irwin > -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2006-12-15 18:53:19
|
On 2006-12-15 09:56+0100 Werner Smekal wrote: > Hi Alan, > > I'll have a look into this topic. Ideally we should provide two packages, one > with Visual Studio C++ 6.0 libraries and one with MinGW libraries. Python and > so on, can use both or at least one of these packages. I'm not aware of > projects which would depend on Borland libraries and so on. Borland/Watcom > users should compile plplot on their on. > > We would need VC++ 6.0 binaries, since all later VC++ can use them, but > obviously if I make the binary with VC++ 2005 not many can use it than :). > Since I have no access to VC++ 6.0, it would be perfect, if Arjen could > provide this package. I intend to provide the mingw package than. If we > sorted out how cpack can do this automatically this should be not much a > problem. There are two issues here (and a third one below): (1) Working out the current bugs in the package target. I suggest you first do that with your MinGW platform since that is obviously an important release platform. Once that is done, then everybody should check that the package target works on their platform of choice (e.g., Linux, Cygwin, VC++ 2005, and VC++ 6.0). I suspect there will be no additional problems for the first two because the package target (once it is working properly) only exercises the various install commands and those have all been thoroughly checked out on those platforms by making sure the install target installs all the files correctly. However, I don't think the install target has yet been tried for VC++ 2005 and VC++ 6.0 so there may be a few additional issues to sort out there. (2) Deciding what platforms to binary release. I think your initial instincts are right on the money here. MinGW is obviously (just from the huge number of downloads at SourceForge for that project) an especially important platform for binary releases. And if VC++ 2005 users can use a VC++ 6.0 binary release, but not vice versa, then it would be good to have a VC++ 6.0 binary release (if Arjen agrees) in addition to the MinGW one. > > Problematic in any case will be how we add the additional libraries? > Freetype, qhull, cd, agg are static (at least for vc++ 6.0) so no problem > here, but wxWidgets can be made static and gd must be provided as dll. So > this needs some research. (3) From the Unix perspective it is extremely rare to build external software as part of your own build. But the Unix guys here are going to have to suspend their cultural beliefs and rely on Werner's and Arjen's windows instincts on this issue for now. Of course, as more and more Unix projects clue in to the power of CMake on windows, you may find in a couple of more years that the need to build external software on windows becomes less and less as windows binary releases become more common (just as will happen for us) for software projects that were developed primarily in the Unix world. Note, we should generally not carry any external source code in our own CVS or source releases, but we certainly have room for the CMakeList.txt files for external software that Werner has already prepared and put into cmake/external/libagg cmake/external/libcd, and cmake/external/libqhull (or any other library that he or Arjen provides CMakeList.txt files for). The addition of a small script to download source for each of those libraries, and the appropriate top-level CMakeLists.txt file changes to optionally build those external libraries as part of the windows build should be quite straightforward and not make any appreciable difference to the size of our CVS or our source releases. Werner, you are now the windows developer in our group with the most CMake experience so if you have some other way you wish to proceed on this issue, that is fine with me as well so long as the principle is followed to not add external source code to our CVS or source releases. 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Jim D. <li...@di...> - 2006-12-15 20:29:47
|
"Alan W. Irwin" <ir...@be...> writes: > On 2006-12-15 09:56+0100 Werner Smekal wrote: > > There are two issues here (and a third one below): > > (1) Working out the current bugs in the package target. I suggest you first > do that with your MinGW platform since that is obviously an important > release platform. Once that is done, then everybody should check that > the package target works on their platform of choice (e.g., Linux, > Cygwin, VC++ 2005, and VC++ 6.0). I suspect there will be no additional > problems for the first two because the package target (once it is > working properly) only exercises the various install commands and those > have all been thoroughly checked out on those platforms by making sure > the install target installs all the files correctly. However, I don't > think the install target has yet been tried for VC++ 2005 and VC++ 6.0 > so there may be a few additional issues to sort out there. > I just tried this build using Visual Studio .NET 2003 and Intel Fortran 9.1. I was able get a successful build using cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=\opt\test -DCMAKE_INSTALL_LIBDIR=\opt\test\lib\i686-pc-win32-ivf -DBUILD_SHARED_LIBS=OFF -G "NMake Makefiles" path_to_source The key line was the "-DBUILD_SHARED_LIBS=OFF" because it would not build otherwise. After a "nmake all" followd by a "nmake install" I noticed the first problem. Install will install relative to the build directory. Not quite what I wanted. So I tried again and inserted a "C:" in the install directory locations and that fixed that problem. As an aside, two really cool things about CMake. First, I think the build runs faster than the ABS version. Second, in the windows build, I can specify a network share as the source file location, e.g. \\server\path\to\plplot\source, and cmake is able to work. I then proceeded to try cpack, and got an empty tar.gz file. I tried cpack with a "-G ZIP" option with no luck either. I tried to use cpack on a linux build (gcc) and at first it didn't work because it could not set permissions in the install directory. A quick "sudo cpack" and I got an empty tar.gz file. I'm using cmake version 2.4-patch 5 -jd |
From: Alan W. I. <ir...@be...> - 2006-12-15 22:29:56
|
Hi Jim: Glad you got the PLplot build to work on your particular windows platform. Arjen and Werner have managed to get shared libraries to work on their own windows platforms, but it sounds like a bit more effort will be required to get the same shared library success on your windows platform. > I then proceeded to try cpack, and got an empty tar.gz file. I tried > cpack with a "-G ZIP" option with no luck either. I tried to use cpack > on a linux build (gcc) and at first it didn't work because it could not > set permissions in the install directory. A quick "sudo cpack" and I > got an empty tar.gz file. cpack needs to be set up properly to work, and that setup is normally done via cmake. See the last part of the top-level CMakeLists.txt file for the _cmake_ source. On Linux, at least, after the cmake command to configure cmake, and the make command to build it, I have confirmed that both "make package" and "make package_source" work. "make package" collects everything that would normally be installed in the install tree (i.e., a binary release) and puts it in a tarball instead. (cmake is set up to make several additional forms of binary release beyond just a tarball when you execute "make package". Those additional forms exist, but I haven't checked their contents.) "make package_source" collects everything in the source tree (except what you exclude with the CPACK_SOURCE_IGNORE_FILES variable) (i.e. a source release) and puts it into a tarball. Jim and Arjen and Werner, do the windows equivalent of "make package" and "make package_source" work for cmake itself on your various windows platforms? If you look in cmake/modules/plplot_version.cmake and the latter part of our top-level CMakeLists.txt file you will see the CPACK related variables we set our very similar to those that already work well for the _cmake_ source. In fact, "make package_source" already works well for us, but "make package" does not work for some reason and the resulting binary release tarball is empty (at least on Linux). I suspect it is some CPACK variable that still needs to be set, but I haven't spotted it yet when comparing with how cmake sets up "make package" for its own binary release(s). This is the "minor debugging" of the subject line, and I hope somebody else will take a look because I am just plain missing what the problem might be. 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2006-12-16 22:39:44
|
On 2006-12-15 14:29-0800 Alan W. Irwin wrote: > [...]In fact, "make package_source" already works well for us, but "make package" > does not work for some reason and the resulting binary release tarball is > empty (at least on Linux). The answer I got on the CMake list is PLplot is running afoul of a current CPack limitation; "make package" only works if you specify paths relative to the value of CMAKE_INSTALL_PREFIX for the DESTINATION of INSTALL commands, and we use absolute paths instead to support our autotools-like variety of INSTALL DESTINATIONs. I know of a possible workaround (use relative install paths whenever the user specifies a common CMAKE_INSTALL_PREFIX leading all installation directories), but it will be a fair amount of work to implement that. There is also some indication on the CMake list that a solution to the current limitation for CPack will be found. One way or another I hope this showstopper for binary releases of PLplot is resolved within the next week or so (bearing in mind that our forthcoming source release will be in mid-January). To prepare for that resolution, I suggest those with windows platforms should try "make install" (which exercises all the INSTALL commands which are used by "make package"). 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2006-12-17 08:38:28
|
Hi Alan, Alan W. Irwin wrote: > On 2006-12-15 14:29-0800 Alan W. Irwin wrote: > >> [...]In fact, "make package_source" already works well for us, but "make package" >> does not work for some reason and the resulting binary release tarball is >> empty (at least on Linux). On Windows make package produces an empty 1kb file (same as in Linux) and make package_source produces an 33MB file, since all my build directories, which are in the plplot directory (plplot/buildnmake, plplot/buildmingw, etc.) are also copied into this pakcage. > > The answer I got on the CMake list is PLplot is running afoul of a current > CPack limitation; "make package" only works if you specify paths relative to > the value of CMAKE_INSTALL_PREFIX for the DESTINATION of INSTALL commands, > and we use absolute paths instead to support our autotools-like variety of > INSTALL DESTINATIONs. I know of a possible workaround (use relative install > paths whenever the user specifies a common CMAKE_INSTALL_PREFIX leading all > installation directories), but it will be a fair amount of work to implement > that. We better wait for a fix, if it's a lot of work for a solution which is needed for maybe only some weeks. > > There is also some indication on the CMake list that a solution to the > current limitation for CPack will be found. One way or another I hope this > showstopper for binary releases of PLplot is resolved within the next week > or so (bearing in mind that our forthcoming source release will be in > mid-January). To prepare for that resolution, I suggest those with windows > platforms should try "make install" (which exercises all the INSTALL > commands which are used by "make package"). Yes, I try make install regularily and it works without problems, all seem to be there. Regards, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2006-12-18 23:32:35
|
On 2006-12-17 09:37+0100 Werner Smekal wrote: > Alan W. Irwin wrote: >> >> There is also some indication on the CMake list that a solution to the >> current limitation for CPack will be found. One way or another I hope >> this >> showstopper for binary releases of PLplot is resolved within the next week >> or so (bearing in mind that our forthcoming source release will be in >> mid-January). To prepare for that resolution, I suggest those with windows >> platforms should try "make install" (which exercises all the INSTALL >> commands which are used by "make package"). > > Yes, I try make install regularily and it works without problems, all seem to > be there. I would like to thank Jim Dishaw who pointed out another "make package" problem off-list which I have verified. If you completely remove your install directory and run the usual "cmake" and "make" followed by "make package" the install directory is populated. This unexpected side effect is especially nasty for the case when the install directory is owned by the root account. It turns out there is an easy work around that solves both the absolute path issue and the install directory population issue. On Linux, this is how I can now make a binary release by hand * rm -rf /staging/area * make install DESTDIR=/staging/area * pushd /staging/area * tar zcf plplot-5.7.1-Linux.tar.gz . * popd * mv /staging/area/plplot-5.7.1-Linux.tar.gz . * rm -rf /staging/area ("/staging/area" is any absolute or relative directory location which you don't mind overwriting.) Werner, if a windows equivalent of the above procedure works, then I suggest you put it into a script for convenience (until make package is fixed), and that should conveniently take care of the fundamental issue of how to make a binary release on windows. The only remaining binary-release issue then appears to be integrating external libraries into the build so that "make install" (for now and "make package" eventually) installs them in DESTDIR. Werner, I have suggested a low-impact way to deal with this remaining issue. What do you think? 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Jim D. <li...@di...> - 2006-12-19 04:55:24
|
"Alan W. Irwin" <ir...@be...> writes: > Werner, if a windows equivalent of the above procedure works, then I suggest > you put it into a script for convenience (until make package is fixed), and > that should conveniently take care of the fundamental issue of how to make a > binary release on windows. The only remaining binary-release issue then > appears to be integrating external libraries into the build so that "make > install" (for now and "make package" eventually) installs them in DESTDIR. > Werner, I have suggested a low-impact way to deal with this remaining issue. > What do you think? > I followed the suggested procedure and put a copy at http://dishaw.org/plplot/ for test purposes. It should work with Visual Studio and Intel Fortran. -jd |
From: Werner S. <sm...@ia...> - 2006-12-19 09:06:25
|
Hi, > * rm -rf /staging/area > > * make install DESTDIR=/staging/area > > * pushd /staging/area > > * tar zcf plplot-5.7.1-Linux.tar.gz . > > * popd > > * mv /staging/area/plplot-5.7.1-Linux.tar.gz . > > * rm -rf /staging/area > > ("/staging/area" is any absolute or relative directory location which you > don't mind overwriting.) > > Werner, if a windows equivalent of the above procedure works, then I suggest > you put it into a script for convenience (until make package is fixed), and > that should conveniently take care of the fundamental issue of how to make a > binary release on windows. The only remaining binary-release issue then > appears to be integrating external libraries into the build so that "make > install" (for now and "make package" eventually) installs them in DESTDIR. > Werner, I have suggested a low-impact way to deal with this remaining issue. > What do you think? A windows script would be easy to write with windows commands apart from the tar stuff - zip should be used on the windows platform and than we would need a zip program also :) (which we would get via gnuwin32.sf.net). Anyway, Jim was already able doing it, so no problem here I think (though he didn't include 3rd party libraries). The problem with including the external libraries, if any, I would suggest to solve on the script level. Just write copy commands in the script, maybe this has to be edited by hand or maybe this could be done during the cmake call or so. But I think this is the best way with the lowest effort. Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Jim D. <ji...@di...> - 2006-12-19 15:26:34
|
Werner Smekal <sm...@ia...> writes: > A windows script would be easy to write with windows commands apart from > the tar stuff - zip should be used on the windows platform and than we > would need a zip program also :) (which we would get via > gnuwin32.sf.net). Anyway, Jim was already able doing it, so no problem > here I think (though he didn't include 3rd party libraries). > What third party libraries do I need to include? |
From: Arjen M. <arj...@wl...> - 2006-12-20 08:07:28
|
Werner Smekal wrote: >Hi Alan, > >I'll have a look into this topic. Ideally we should provide two >packages, one with Visual Studio C++ 6.0 libraries and one with MinGW >libraries. Python and so on, can use both or at least one of these >packages. I'm not aware of projects which would depend on Borland >libraries and so on. Borland/Watcom users should compile plplot on their on. > >We would need VC++ 6.0 binaries, since all later VC++ can use them, but >obviously if I make the binary with VC++ 2005 not many can use it than >:). Since I have no access to VC++ 6.0, it would be perfect, if Arjen >could provide this package. I intend to provide the mingw package than. >If we sorted out how cpack can do this automatically this should be not >much a problem. > >Problematic in any case will be how we add the additional libraries? >Freetype, qhull, cd, agg are static (at least for vc++ 6.0) so no >problem here, but wxWidgets can be made static and gd must be provided >as dll. So this needs some research. > > (I am late in replying, because of a rather nasty flu. I have not read the other replies yet) Yes, I can provide libraries for MSVC 6.0. That ought to help with all the language bindings that rely on bare Windows. The problem with the additional libraries is that right now we rely on them being present at build-time and at run-time - we do not have mechanisms to detect whether they are actually available at run-time. Nothing to worry about in the current way of working, but a nuisance when we deliver binaries: If a program that relies (directly or indirectly) on a DLL (like gd.dll) can not find it at start-up, you may get a message about it not being able to find some DLL _or_ it just dies. I know of no way to prevent that from happening, unless we explicitly load the DLL - in a libtool-like fashion. Anyway, just some preliminary remarks about this next step, which ought to be a very good one. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-12-20 08:23:41
|
Hi Arjen, > The problem with the additional libraries is that right now we rely on them > being present at build-time and at run-time - we do not have mechanisms > to detect > whether they are actually available at run-time. Nothing to worry about > in the > current way of working, but a nuisance when we deliver binaries: > > If a program that relies (directly or indirectly) on a DLL (like gd.dll) > can not > find it at start-up, you may get a message about it not being able to > find some > DLL _or_ it just dies. I know of no way to prevent that from happening, > unless > we explicitly load the DLL - in a libtool-like fashion. I think the way to go is the way Alan and I agreed on. Write batch files which you and I use to make these packages "privately". It should work like that: 1) Having a working plplot library, with all libraries included, which we want to include - in the moment gd, freetype, cd, wxwidgets, agg, qhull are external, while only gd and wxwidgets are actually dlls for Visual C++ 6.0 (others are statically linked in). 2) Run a batch file, which runs: a) make package b) untar the package somewhere temporarily (since tar is no good for windows) c) copy possible dlls into the directory where plplotd.dll resides d) zip it You need only tar and zip from somewhere (e.g. gnuwin32.sf.net), since windows doesn't provide it by default You don't have any more problems regarding the external dlls, since they are in the same place as plplotd.dll - and if plplotd.dll can be found, all other dlls can be found as well. I think this is the way to go - this would be no "official" batch file, just one for you and me, or others who are interested in providing binaries for some configuration we don't have. Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Werner S. <sm...@ia...> - 2006-12-20 08:29:45
|
Hi Jim, > > What third party libraries do I need to include? You don't need to include them, but they provide additional functionality or drivers. In the moment these are: * gd library - used for the gd driver (png, jpeg, gif output) * freetype library - used for nice font rendering in some drivers (e.g. wingcc) * qhull library - not sure actually, but I think it is used for interpolation in grids, so they look more nicely (or something similar :) * cd library - used for the cd driver (cd output) * wxWidgets library - used for the wxWidgets driver * AGG library - used in the wxWidgets driver to get antialized rendering All these libraries work and compile on Windows and the instructions can be found here: http://www.miscdebris.net/plplot_wiki/index.php?title=Install_3rd_party_libraries Or actually will be found at this position if I manage to complete them :). But in the progress of making a binary package I will complete this instructions and it would be cool if someone would test them. Werner |
From: Arjen M. <arj...@wl...> - 2006-12-20 09:59:02
|
Werner Smekal wrote: > >* qhull library - not sure actually, but I think it is used for >interpolation in grids, so they look more nicely (or something similar :) > > qhull is a library/program to determine the convex hull of a set of points in n dimensions. The CSIRO library that is part of PLplot uses this for certain interpolation methods. (Convex hulls in n dimensions are related to Voronoi diagrams and Delaunay triangulations in n-1 dimensions). Regards, Arjen |
From: Jim D. <li...@di...> - 2006-12-20 13:32:22
|
Werner Smekal <sm...@ia...> writes: > * gd library - used for the gd driver (png, jpeg, gif output) > * freetype library - used for nice font rendering in some drivers (e.g. > wingcc) > * qhull library - not sure actually, but I think it is used for > interpolation in grids, so they look more nicely (or something similar :) > * cd library - used for the cd driver (cd output) > * wxWidgets library - used for the wxWidgets driver > * AGG library - used in the wxWidgets driver to get antialized rendering > I will try to make a version that includes them--I'll probably offer a plain vanilla version in addition to the additional library version. -jd |
From: Alan W. I. <ir...@be...> - 2006-12-20 16:53:50
|
On 2006-12-20 09:23+0100 Werner Smekal wrote: > 2) Run a batch file, which runs: > a) make package > b) untar the package somewhere temporarily (since tar is no good for > windows) > c) copy possible dlls into the directory where plplotd.dll resides > d) zip it > > You need only tar and zip from somewhere (e.g. gnuwin32.sf.net), since > windows doesn't provide it by default One small change I would recommend is to use unzip in step b) to reduce the tool dependencies. I think this is consistent with what cpack does on windows. See http://cmake.org/HTML/Download.html for an example of zip results produced by cpack on windows). Regardless of this minor issue, it appears we have arrived at a viable method to make binary releases for our windows users, and I think we are going to see our PLplot efforts have a lot more impact in the windows world as a result. 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2007-01-02 23:39:36
Attachments:
make_win_package.batch
|
(Repost with renamed file ending, so that it gets through spam/virus checks) Hi, I wrote and tested now a batch file, which assembles a binary package of plplot for MinGW or Visual C++ and can easily adjusted for other compilers. It copies the dlls of the gd, libharu and wxwidgets libraries if available - so you don't need them, but we should add them for a complete binary package. You need in any case the zip executable, e.g. from here http://gnuwin32.sourceforge.net/packages/zip.htm , you need only the binaries. Put them somewhere in the path. The batch file awaits, that the plplot library is already configured via cmake, build and installed. You need to adjust the settings at the top of the file. Alan, where should I put this script in the repository? Is the script directory alright? I post tomorrow my MinGW package (I can't provide Visual C++, since I have only Visual C++ 2005), how I made it and I'll also post my 3rd party libraries package, which allows to compile 6 libraries with one command. Regards, Werner > One small change I would recommend is to use unzip in step b) to reduce the > tool dependencies. I think this is consistent with what cpack does on > windows. See http://cmake.org/HTML/Download.html for an example of zip > results produced by cpack on windows). > > Regardless of this minor issue, it appears we have arrived at a viable method > to make binary releases for our windows users, and I think we are going to > see our PLplot efforts have a lot more impact in the windows world as a result. > > Alan -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2007-01-03 01:41:36
|
On 2007-01-03 00:39+0100 Werner Smekal wrote: > Alan, where should I put this script in the repository? Is the script > directory alright? Yes. > > I post tomorrow my MinGW package (I can't provide Visual C++, since I > have only Visual C++ 2005), how I made it and I'll also post my 3rd > party libraries package, which allows to compile 6 libraries with one > command. After the windows users on this list have evaluated your packages you will want to release them at SourceForge (and also announce those releases at SourceForge, plplot-devel and plplot-general just like Hazen does for our PLplot source releases.) Werner, you and Arjen are de facto the release managers for all the windows-related packages so here are my comments/suggestions on this new role for you. I suggest you put your procedures for preparing your releases as Section 4 (preparation of third-party windows library packages) and Section 5 (preparation of PLplot windows packages) of README.Release_Manager_Cookbook. At this point you may want to consult README.Release_Manager_Cookbook to see what it specifically says about file releases at SourceForge. The package name should continue to be "plplot", but I have some suggestions for the names of your releases. (Note, the release name is a short descriptive name that appears at our file release area at SourceForge and is completely independent of the file name that you decide to use for your release.) We traditionally name our PLplot source releases as "5.x.x Source" to distinguish from rpm binary and rpm source releases we have made in the past. This tradition was not followed for 5.7.1 and 5.7.0. Nevertheless, Hazen, I suggest you name the planned January source release "5.7.2 Source" to be consistent with the tradition and also to distinguish it from Werner and Arjen's binary releases. Werner and Arjen, you might want to call your 3rd-party release something like 1.0.0-RC1 Third-party library Source 1.0.0-RC1 Third-party library MinGW binary 1.0.0-RC1 Third-party library Visual C++ binary and your PLplot binary releases 5.7.2 MinGW binary 5.7.2 Visual C++ binary With regard to your 3rd-party packages, I have assumed you want to make one or more release candidates (RC1, RC2, etc.) for everybody to try before you finalize 1.0.0. Also, I have assumed that your third-party packages should have a numbering scheme that differs from the PLplot one since there should be a different (hopefully less) rate of version churn for the third-party packages than for PLplot itself. In particular, you can be completely independent about when you release the third party packages, but your 5.x.x binary releases should be generated from Hazen's source release tarball with the same (PLplot) version number so must appear after he has made his source release. With regard to all your file releases at SF, I think it is important that you provide an armored ascii signature file using gpg facilities (like Hazen does for his source releases). (A google search revealed http://www.glump.net/dokuwiki/gpg/gpg_intro as a possible set of directions for installing gpg on windows.) The detached GPG signature file for our releases identifies you as responsible for these files. That is fundamentally important from a security perspective since it assures careful users they have downloaded a clean copy which is exactly the same as the one you (and only you) uploaded to SourceForge. Finally, I would like to publicly thank our release managers, Werner, Arjen, and Hazen in advance for making their planned file releases at SourceForge. Those releases are fundamentally important not only for quickly propagating our latest PLplot development efforts to large numbers of users, but also as a source of good publicity for PLplot. 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2007-01-05 09:55:40
|
Ok, I uploaded the mingw package for testing here: http://www.miscdebris.net/stuff/plplot-5.7.1-mingw-binary.zip This should contain all needed to start using plplot for mingw without compiling itself. It contains all drivers available for windows also wxwidgets. I produced it like that: 1) cd plplot 2) mkdir build 3) cd build 4) cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=local -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DwxWidgets_LIB_DIR=%WXWIN%/lib/gcc_dll -DwxWidgets_CONFIGURATION=msw -DENABLE_MIX_CXX=ON -DENABLE_java=OFF -DENABLE_python=OFF -DENABLE_tcl=OFF -DPLD_svg=ON -DPLD_pdf=ON .. 5) mingw32-make install 6) cd .. 7) check scripts/make_win_package.bat (version number, settings) 8) scripts\make_win_package.bat The dlls and libs are in the lib directory. The header files are in include/plplot. You need to set the PATH variable to the lib directory so that windows can find the dlls. I already tested it and it worked well. I'll update the release managers cookbook. I'll check the gpg stuff, I have it already but never signed a package so far. Alan, I also want to include into this zip a small readme file, where I explain in short how to use it, and also two batch files (mingw, vc) which should compile x01c.c just for test purposes (for the user and the packager). Where should I copy this Readme file in the plplot repository? doc? The batch files go into scripts again, or? Regards, Werner Alan W. Irwin wrote: > On 2007-01-03 00:39+0100 Werner Smekal wrote: > >> Alan, where should I put this script in the repository? Is the script >> directory alright? > > Yes. > >> I post tomorrow my MinGW package (I can't provide Visual C++, since I >> have only Visual C++ 2005), how I made it and I'll also post my 3rd >> party libraries package, which allows to compile 6 libraries with one >> command. > > After the windows users on this list have evaluated your packages you will > want to release them at SourceForge (and also announce those releases at > SourceForge, plplot-devel and plplot-general just like Hazen does for our > PLplot source releases.) > > Werner, you and Arjen are de facto the release managers for all the > windows-related packages so here are my comments/suggestions on this new > role for you. > > I suggest you put your procedures for preparing your releases as Section 4 > (preparation of third-party windows library packages) and Section 5 > (preparation of PLplot windows packages) of README.Release_Manager_Cookbook. > > At this point you may want to consult README.Release_Manager_Cookbook to see > what it specifically says about file releases at SourceForge. The package > name should continue to be "plplot", but I have some suggestions for the > names of your releases. (Note, the release name is a short descriptive name > that appears at our file release area at SourceForge and is completely > independent of the file name that you decide to use for your release.) We > traditionally name our PLplot source releases as "5.x.x Source" to > distinguish from rpm binary and rpm source releases we have made in the > past. This tradition was not followed for 5.7.1 and 5.7.0. Nevertheless, > Hazen, I suggest you name the planned January source release "5.7.2 Source" > to be consistent with the tradition and also to distinguish it from Werner > and Arjen's binary releases. > > Werner and Arjen, you might want to call your 3rd-party release something like > > 1.0.0-RC1 Third-party library Source > 1.0.0-RC1 Third-party library MinGW binary > 1.0.0-RC1 Third-party library Visual C++ binary > > and your PLplot binary releases > > 5.7.2 MinGW binary > 5.7.2 Visual C++ binary > > With regard to your 3rd-party packages, I have assumed you want to make one > or more release candidates (RC1, RC2, etc.) for everybody to try before you > finalize 1.0.0. Also, I have assumed that your third-party packages should > have a numbering scheme that differs from the PLplot one since there should > be a different (hopefully less) rate of version churn for the third-party > packages than for PLplot itself. In particular, you can be completely > independent about when you release the third party packages, but your 5.x.x > binary releases should be generated from Hazen's source release tarball with > the same (PLplot) version number so must appear after he has made his source > release. > > With regard to all your file releases at SF, I think it is important that > you provide an armored ascii signature file using gpg facilities (like Hazen > does for his source releases). (A google search revealed > http://www.glump.net/dokuwiki/gpg/gpg_intro as a possible set of directions > for installing gpg on windows.) The detached GPG signature file for our > releases identifies you as responsible for these files. That is > fundamentally important from a security perspective since it assures careful > users they have downloaded a clean copy which is exactly the same as the one > you (and only you) uploaded to SourceForge. > > Finally, I would like to publicly thank our release managers, Werner, Arjen, > and Hazen in advance for making their planned file releases at SourceForge. > Those releases are fundamentally important not only for quickly propagating > our latest PLplot development efforts to large numbers of users, but also as > a source of good publicity for PLplot. > > Alan > __________________________ -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2007-01-05 17:25:47
|
On 2007-01-05 10:55+0100 Werner Smekal wrote: > Alan, I also want to include into this zip a small readme file, where I > explain in short how to use it, and also two batch files (mingw, vc) which > should compile x01c.c just for test purposes (for the user and the packager). > Where should I copy this Readme file in the plplot repository? doc? > > The batch files go into scripts again, or? These files are all related to a (windows) binary release of PLplot so I suggest using a new directory called binary_release for all of them. I find readme files are sometimes moved into different directories for installs, etc., so I further suggest putting a suffix on the readme file name (e.g., readme.binary_release) to distinguish it from all other readme's. Furthermore, I suggest you "cvs add" make_all_vc.bat and make_all_mingw.bat (and associated readme.third_party) as well since I am sure both you and Arjen (and Jim) will want to update those files over time using our CVS facilities. Since these are all related to third-party libraries, I suggest the name of the directory for these files should be third_party. Since both binary_release and third_party are windows related, you may want to put both those new subdirectories under a new top-level subdirectory called windows. Note, I sometimes have trouble inventing descriptive names of new subdirectories so if you can think of better names, that is fine. Also, make sure you have made the final decision on the subdirectory name before you cvs commit since cvs does not allow you to remove a subdirectory once its been committed. 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2007-01-09 07:43:32
|
Hi Werner, I tested the batch file "make_all_vc.bat" this morning. Here are my results: - I ran it in a separate DOS-box - Preparation includes: - running vcvars32 - otherwise CMake can not identify the proper compilers - making sure CMake in the path - A minor but important fix is needed: mkdir lib (just like: mkdir build) This is needed for both make_all_vc.bat and make_all_mingw.bat - It all compiled and linked without any apparent problems after that. I have not tested the make_win_package.bat batch file yet. Suggestions/questions: - Add a pause after CMake: any problems involving CMake (it not being in the path or no suitable compiler) will be clearly in view then - I noticed the various libraries are not all stored in ...\lib - is there a specific reason for this? (the agg, qhull, ... libraries are stored in build\aggx.y etc) Not really important probably, just confusing Regards, Arjen |
From: Werner S. <sm...@ia...> - 2007-01-10 09:10:19
|
Hi Arjen, > I tested the batch file "make_all_vc.bat" this morning. Here are my results: > - I ran it in a separate DOS-box > - Preparation includes: > - running vcvars32 - otherwise CMake can not identify the proper compilers > - making sure CMake in the path As this is exactly my setup I develop with, I forgot to mention that. I'll add a description on the wiki how to setup a simple automatic solution for that. > - A minor but important fix is needed: mkdir lib (just like: mkdir build) > This is needed for both make_all_vc.bat and make_all_mingw.bat Not if cmake was installed correctly. First the agg,qhull,cd library are built and installed (nmake install). As install directories I specified the usual suspects (bin/lib/include) and cmake has no problem to create this libraries if they don't exist. But if that steps fails, since cmake wasn't found or so, it compiles freetype next, and copies the libraries by hand to a non existant directory than. So if cmake is found and the compiler correctly setup there should be no problem. > Suggestions/questions: > - Add a pause after CMake: any problems involving CMake > (it not being in the path or no suitable compiler) will be clearly in view > then I redirect all output to log files in the main directory. What doesn't work is error handling. Maybe I try to handle the errors for the first cmake, if cmake isn't in the path or can't find the compiler it will fail and I should catch this error. If it gets through the first cmake than everything should work, so maybe I need only to catch one error. Alternatively I can remove this log redirection, a add a pause after each library compilation, and the user can check if all went well. Also sort of error handling :) > - I noticed the various libraries are not all stored in ...\lib - is > there a > specific reason for this? (the agg, qhull, ... libraries are stored in > build\aggx.y etc) > Not really important probably, just confusing They should all be in lib (because of nmake install) so there went something wrong. Check either the log files. Better would be to delete the whole directory and start from scratch (unzip the package) and try again with cmake in path and vcvars.bat already run. Than it should work. Also don't run mingw and vcvars in the same directory, since this won't work. I have two directories 3p_plot_mingw and 3p_plot_vc (and 3p_plot_wv and 3p_plot_bcc and ...) for that reason. Please tell me if that works than for you. Thanks, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |