From: Hazen B. <hba...@ma...> - 2009-07-24 00:07:31
|
I'd like to start offering a Windows binary and/or an installer along with our source releases. I now have access to a Windows box which I can put pretty much anything on to, i.e. Qt, WxWidgets, Cairo(?), etc... so I'm volunteering myself to generate whatever binaries needs to be generated to make this happen. This has come up several times in the past and then died off so I'm not really sure where things stand. So, to start, what needs to be done to provide a minimalist version of PLplot with the basic windows drivers (wingcc?) with working C examples? Do we need to provide both MinGW and Visual Studio versions of the dlls? I think an official looking Windows installer might be a nice feature and I was looking at WiX (http://wix.sourceforge.net/) as one option. Any suggestions here? Or is what we are installing simple enough so that a .zip file is sufficient and we shouldn't bother with an installer? -Hazen |
From: Werner S. <sm...@ia...> - 2009-07-24 06:50:20
Attachments:
buildPLplot.kix
|
Hi Hazen, On 24.07.2009, at 02:06, Hazen Babcock wrote: > > I'd like to start offering a Windows binary and/or an installer along > with our source releases. I now have access to a Windows box which I > can > put pretty much anything on to, i.e. Qt, WxWidgets, Cairo(?), etc... > so > I'm volunteering myself to generate whatever binaries needs to be > generated to make this happen. This has come up several times in the > past and then died off so I'm not really sure where things stand. > So, to > start, what needs to be done to provide a minimalist version of PLplot > with the basic windows drivers (wingcc?) with working C examples? Do > we > need to provide both MinGW and Visual Studio versions of the dlls? I'm actually "working" on this and already have something which provides the basic PLplot package. Adding other stuff gets then more and more "problematic". On one side is the size a problem. Putting QT and wxWidgets library into the (same) package will likely lead to a really *huge* download. In addition getting all cairo dependencies into the package is not easy and makes a big download. Also the compiler problem is not easy. In principle it's possible for both compilers to use a plplot dll created by another compiler, except functions which return a file handle (do we have any?). I'm also not sure if e.g. Visual C++ 2005 is able to use dlls form Visual C++ 2008 and vice versa - this obviously difficult to test if you only have one computer. So I would just provide a package for MinGW (3.4.5) and Visual C++ 2008 - should be not so much a problem if we using a batch file (see below). > > I think an official looking Windows installer might be a nice feature > and I was looking at WiX (http://wix.sourceforge.net/) as one option. > Any suggestions here? Or is what we are installing simple enough so > that > a .zip file is sufficient and we shouldn't bother with an installer? In no case I would use an installer. It just makes the package bigger for no obvious advantage. I think the minimal requirement of a Windows developer must be, that he is able to unzip a file. Zip file it must be, since tar.gz packages are not common. Anyway the way I went and I think that's the correct one, since I have done that for other libraries as well is to provide a batch file which can be configured to produce the configuration in question on it's own using only plplot source and the compiler. It downloads necessary libraries (via curl) and unzips them (via 7zip), even compiles them (cmake) and then copies all together in one package. The big advantage of that is, that you only need run the batch file and everything gets created at once. No need to install any other libraries before. Problem here is that you need to use Windows CLI commands, since bash scripts or so don't work well on Windows even with winbash - and it's always best to use native tools, especially if you don't do cross platform here. I also consider(ed) to use kixtart (http://www.kixtart.org/ ) which is quite common on Windows, easy to install (just one exe) - actually I used it already. Attached you will find a batch file which creates a plplot package already including the qhull library. Not well tested so problems may occur. But in my opinion starting from here is the best solution. It's easy for someone else to make a package as well, he just needs a compiler, cmake, kixtart, curl and 7zip all of them are easy to install. What do you think? Regards, Werner > > -Hazen > > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. 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: Arjen M. <arj...@de...> - 2009-08-03 06:43:15
|
On 2009-07-24 08:49, Werner Smekal wrote: > Hi Hazen, > > > I'm actually "working" on this and already have something which provides > the basic PLplot package. Adding other stuff gets then more and more > "problematic". On one side is the size a problem. Putting QT and > wxWidgets library into the (same) package will likely lead to a really > *huge* download. In addition getting all cairo dependencies into the > package is not easy and makes a big download. Also the compiler problem > is not easy. In principle it's possible for both compilers to use a > plplot dll created by another compiler, except functions which return a > file handle (do we have any?). I'm also not sure if e.g. Visual C++ 2005 > is able to use dlls form Visual C++ 2008 and vice versa - this obviously > difficult to test if you only have one computer. So I would just provide > a package for MinGW (3.4.5) and Visual C++ 2008 - should be not so much > a problem if we using a batch file (see below). Hello Werner, I think Visual C/C++ 6.0 (yes, ancient) leads to the most portable DLLs. This has to do with the run-time libraries that you need to supply/rely on. When it comes to bindings for other languages than C, difficulties arise: for Fortran, for instance, some compilers will use one form of name mangling or one particular calling convention, others will use alternatives. This is partly due to the fact that DLLs on Windows can use different calling conventions and not all compilers support all of them. I quite agree that we should not try to cover the full range of compilers and platforms: that will turn out to be a horrendous mess. > >> >> I think an official looking Windows installer might be a nice feature >> and I was looking at WiX (http://wix.sourceforge.net/) as one option. >> Any suggestions here? Or is what we are installing simple enough so that >> a .zip file is sufficient and we shouldn't bother with an installer? > > In no case I would use an installer. It just makes the package bigger > for no obvious advantage. I think the minimal requirement of a Windows > developer must be, that he is able to unzip a file. Zip file it must be, > since tar.gz packages are not common. > > What do you think? > I agree: a Windows installer may look attractive, but it is an extra burden with little nett advantage. (I will have to have a look at your batch files - will do so later) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2009-07-24 07:59:38
|
On 2009-07-23 20:06-0400 Hazen Babcock wrote: > > I'd like to start offering a Windows binary and/or an installer along > with our source releases. I now have access to a Windows box which I can > put pretty much anything on to, i.e. Qt, WxWidgets, Cairo(?), etc... so > I'm volunteering myself to generate whatever binaries needs to be > generated to make this happen. This has come up several times in the > past and then died off so I'm not really sure where things stand. So, to > start, what needs to be done to provide a minimalist version of PLplot > with the basic windows drivers (wingcc?) with working C examples? Do we > need to provide both MinGW and Visual Studio versions of the dlls? Thanks for resurrecting this good idea. Note, binary distributions of PLplot were problematic for CPack (an empty tarball was produced) when I tried that capability several years ago. There was a workaround for the problem at that time, but I cannot remember the details. That issue may be fixed now, but before you get too far into planning this you should try some experiments with cpack to make sure it works the way you expect (i.e., it packages up the install tree). There are a number of cpack articles in the cmake wiki which should be a big help to you in learning how to use cpack to create a binary release. You can find those articles by using the search box of the wiki to look for everything related to "cpack". (That's how I found the list of CPack binary package formats discussed below.) Also note that my new CMake-based build system for the installed examples _should_ work on Windows (unlike the traditional Makefile+pkg-config approach) so it should be quite useful for Windows users of your planned binary package. But as far as I know, it hasn't been tested yet by our developers with access to a Windows box so it may need some additional work for that platform. > > I think an official looking Windows installer might be a nice feature > and I was looking at WiX (http://wix.sourceforge.net/) as one option. > Any suggestions here? Or is what we are installing simple enough so that > a .zip file is sufficient and we shouldn't bother with an installer? To start, I would just go with what CPack provides. See http://www.cmake.org/Wiki/CMake:CPackPackageGenerators. Wix is not on that list of binary package formats, but if you do a google for wix and cpack you will see there is quite a bit of interest so I assume eventually it will be available as a cpack option (or you might want to create that option yourself with the appropriate CMake scripts for cpack). Note, that CPack simply packages what is in the install tree. That is the normal approach used for Linux binary packages, and I think we should stick with that approach. You may get some call to include external libraries which the PLplot core library or the PLplot device drivers depend upon, but I would suggest you will want to resist that pressure because it would make the binary release of PLplot enormous! If you just take the qt/lib part of the Qt4 SDK download, that requires 351M (!), and I assume the pango/cairo stack of libraries has a similar size. I haven't tried it, but I believe if you went with a pure static library build, then our libraries and device drivers would only have the subset of Qt4 code we need embedded, but there would be much duplication of that (and lots of other library) code so that approach is unlikely to give you a net benefit in terms of size. This binary packaging issue has long since been settled for Linux distributions; shared library builds are the defacto standard to save on size, and furthermore, the user is expected to install the (shared) libraries he needs to make your shared libraries and shared objects (dynamic device drivers) work. I think that is the right way to go (assuming you educate Windows users about this binary packaging perspective by giving them good directions about exactly what libraries a binary release of PLplot needs, and where those libraries can be found), but those with actual Windows experience may have a quite different perspective than mine. :-) 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 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: Hazen B. <hba...@ma...> - 2009-07-24 19:13:00
|
Werner Smekal wrote: > Hi Hazen, > > On 24.07.2009, at 02:06, Hazen Babcock wrote: > >> >> I'd like to start offering a Windows binary and/or an installer along >> with our source releases. I now have access to a Windows box which I can >> put pretty much anything on to, i.e. Qt, WxWidgets, Cairo(?), etc... so >> I'm volunteering myself to generate whatever binaries needs to be >> generated to make this happen. This has come up several times in the >> past and then died off so I'm not really sure where things stand. So, to >> start, what needs to be done to provide a minimalist version of PLplot >> with the basic windows drivers (wingcc?) with working C examples? Do we >> need to provide both MinGW and Visual Studio versions of the dlls? > > I'm actually "working" on this and already have something which provides > the basic PLplot package. Adding other stuff gets then more and more > "problematic". On one side is the size a problem. Putting QT and > wxWidgets library into the (same) package will likely lead to a really > *huge* download. In addition getting all cairo dependencies into the > package is not easy and makes a big download. Also the compiler problem > is not easy. In principle it's possible for both compilers to use a > plplot dll created by another compiler, except functions which return a > file handle (do we have any?). I'm also not sure if e.g. Visual C++ 2005 > is able to use dlls form Visual C++ 2008 and vice versa - this obviously > difficult to test if you only have one computer. So I would just provide > a package for MinGW (3.4.5) and Visual C++ 2008 - should be not so much > a problem if we using a batch file (see below). I was thinking of just providing the relevant PLplot dlls for working with Qt, etc, rather than actually including Qt, etc, in our distribution. I don't think this is totally orthogonal to typical Windows style as programs like PyQt do not come with Python. The user would be responsible for downloading mingw, Qt, etc, depending on their own needs. However, perhaps then we'd start having problems with incompatible dlls? >> I think an official looking Windows installer might be a nice feature >> and I was looking at WiX (http://wix.sourceforge.net/) as one option. >> Any suggestions here? Or is what we are installing simple enough so that >> a .zip file is sufficient and we shouldn't bother with an installer? > > In no case I would use an installer. It just makes the package bigger > for no obvious advantage. I think the minimal requirement of a Windows > developer must be, that he is able to unzip a file. Zip file it must be, > since tar.gz packages are not common. > > Anyway the way I went and I think that's the correct one, since I have > done that for other libraries as well is to provide a batch file which > can be configured to produce the configuration in question on it's own > using only plplot source and the compiler. It downloads necessary > libraries (via curl) and unzips them (via 7zip), even compiles them > (cmake) and then copies all together in one package. The big advantage > of that is, that you only need run the batch file and everything gets > created at once. No need to install any other libraries before. Problem > here is that you need to use Windows CLI commands, since bash scripts or > so don't work well on Windows even with winbash - and it's always best > to use native tools, especially if you don't do cross platform here. I > also consider(ed) to use kixtart (http://www.kixtart.org/) which is > quite common on Windows, easy to install (just one exe) - actually I > used it already. > > Attached you will find a batch file which creates a plplot package > already including the qhull library. Not well tested so problems may > occur. But in my opinion starting from here is the best solution. It's > easy for someone else to make a package as well, he just needs a > compiler, cmake, kixtart, curl and 7zip all of them are easy to install. My preference would be some sort of pre-compiled binary, basically a zip of c:\program files\plplot, which I think is what Alan was discussing with cpack. Someone who already knows that they want to use PLplot is probably willing to install all of the pre-dependencies, but someone who is simply trying to evaluate it might not be so excited. However these two approaches are not mutually exclusive. How about we put your script in the repo in say sys/win32? Then we can work on the testing, etc. Once we're happy with the stability and performance we can add directions about how to use it to the wiki. Down the road we could then use it to generate our pre-compiled binaries if we decide to go that route. -Hazen |
From: Werner S. <sm...@ia...> - 2009-07-25 10:59:20
|
Hi Hazen, > I was thinking of just providing the relevant PLplot dlls for working > with Qt, etc, rather than actually including Qt, etc, in our > distribution. I don't think this is totally orthogonal to typical > Windows style as programs like PyQt do not come with Python. The user > would be responsible for downloading mingw, Qt, etc, depending on > their > own needs. However, perhaps then we'd start having problems with > incompatible dlls? For wxWidgets this is not possible since there is no binary release of wxWidgets. I wouldn't also suggest that for QT, because that means the users (!) of plplot would be forced to download a >140MB QT release just to create a simple plot. I don't think that this is a good idea. AFAIK, you just need to include one dll, this shouldn't be a problem (though it will also increase the file size considerably). Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 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...> - 2009-07-25 10:59:24
|
>> Hi Hazen, >> zip all of them are easy to install. > > My preference would be some sort of pre-compiled binary, basically a > zip of c:\program files\plplot, which I think is what Alan was > discussing with cpack. Someone who already knows that they want to > use PLplot is probably willing to install all of the pre- > dependencies, but someone who is simply trying to evaluate it might > not be so excited. You misunderstood me here. The batch file creates a plplot dll and installs everything into one directory. Then you zip it as you want it. In that way we have a easy way for us developers to create such a binary distribution. If you do without a batch file, you need to do a lot of steps over and over again for every new release and you'll be the only one who can do the binary release. It may not be clear, what libraries you included etc. With a batch file this is all "standardized". Regards, Werner > > However these two approaches are not mutually exclusive. How about > we put your script in the repo in say sys/win32? Then we can work on > the testing, etc. Once we're happy with the stability and > performance we can add directions about how to use it to the wiki. > Down the road we could then use it to generate our pre-compiled > binaries if we decide to go that route. > > -Hazen > -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 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: Hazen B. <hba...@ma...> - 2009-07-24 19:26:38
|
Alan W. Irwin wrote: > On 2009-07-23 20:06-0400 Hazen Babcock wrote: > >> >> I'd like to start offering a Windows binary and/or an installer along >> with our source releases. I now have access to a Windows box which I can >> put pretty much anything on to, i.e. Qt, WxWidgets, Cairo(?), etc... so >> I'm volunteering myself to generate whatever binaries needs to be >> generated to make this happen. This has come up several times in the >> past and then died off so I'm not really sure where things stand. So, to >> start, what needs to be done to provide a minimalist version of PLplot >> with the basic windows drivers (wingcc?) with working C examples? Do we >> need to provide both MinGW and Visual Studio versions of the dlls? > > Thanks for resurrecting this good idea. > > Note, binary distributions of PLplot were problematic for CPack (an empty > tarball was produced) when I tried that capability several years ago. > There > was a workaround for the problem at that time, but I cannot remember the > details. That issue may be fixed now, but before you get too far into > planning this you should try some experiments with cpack to make sure it > works the way you expect (i.e., it packages up the install tree). There > are > a number of cpack articles in the cmake wiki which should be a big help to > you in learning how to use cpack to create a binary release. You can find > those articles by using the search box of the wiki to look for everything > related to "cpack". (That's how I found the list of CPack binary package > formats discussed below.) Thanks for the pointers, I'll have a look. > Also note that my new CMake-based build system for the installed examples > _should_ work on Windows (unlike the traditional Makefile+pkg-config > approach) so it should be quite useful for Windows users of your planned > binary package. But as far as I know, it hasn't been tested yet by our > developers with access to a Windows box so it may need some additional work > for that platform. I'll give it a test. I assume you are referring to the what you discussed in your May e-mails "Status of the new CMake-based build system for the installed examples"? Maybe we should add those instructions to the wiki and/or update README.testing? >> I think an official looking Windows installer might be a nice feature >> and I was looking at WiX (http://wix.sourceforge.net/) as one option. >> Any suggestions here? Or is what we are installing simple enough so that >> a .zip file is sufficient and we shouldn't bother with an installer? > > To start, I would just go with what CPack provides. See > http://www.cmake.org/Wiki/CMake:CPackPackageGenerators. Wix is not on that > list of binary package formats, but if you do a google for wix and cpack > you > will see there is quite a bit of interest so I assume eventually it will be > available as a cpack option (or you might want to create that option > yourself with the appropriate CMake scripts for cpack). Sounds good. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-07-24 23:47:09
|
On 2009-07-24 15:25-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> Also note that my new CMake-based build system for the installed examples >> _should_ work on Windows (unlike the traditional Makefile+pkg-config >> approach) so it should be quite useful for Windows users of your planned >> binary package. But as far as I know, it hasn't been tested yet by our >> developers with access to a Windows box so it may need some additional work >> for that platform. > > I'll give it a test. That's great. I am really keen to make sure this new build system for our installed examples works just as well on Windows as it currently does on my Linux platform so I will try to give you fast turnaround if you discover some inadvertent cross-platform issues. However, such issues should be fairly limited since most of the scripts used are identical to what is used for ctest of the build tree (which both Arjen and Werner say works for them.) However, just to be sure you get the same results they do, I suggest you try ctest first. Once you have confirmed that is working for you, then you should be in good shape to test the new install-tree build system (on any platform. I don't think it has been tested on Mac's, either.) > I assume you are referring to the what you discussed in > your May e-mails "Status of the new CMake-based build system for the > installed examples"? Yes. > Maybe we should add those instructions to the wiki > and/or update README.testing? Yes. I plan to do this before the forthcoming release unless someone else beats me to it. 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 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: Steve S. <s.s...@im...> - 2009-07-25 11:02:38
|
I think I saw a comment under this thread that shipping the Qt libraries to make a self-contained windows installation would be excessively large (350 MB from my memory). This probably is far more than is necessary simply to use the qt devices. We ship binaries of our QSAS application for windows with all the necessary qt libraries. At rough calculation the qt dll's take up about 17 MB. (our entire application is zipped into 38 MB). Of course, if the use wants to build a qt application they'll need the full Qt sdk, but to be able to drive the qt device only requires a handful of dll's. Alban may/will be better able to advise, but it must be straightforward to work out what libs the qt device actually loads. This would have the same advantage for you as it does for us, namely a self-contained binary distribution that doesn't require any external capabilities (e.g., X, cairo, etc., etc.) and handles a full set of devices. Regards, Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7900 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 711A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2009-07-25 17:55:53
|
Hi Steve: The first part of this responds to your suggestion, but I also have a response to Werner's suggestion at the end. On 2009-07-25 12:02+0100 Steve Schwartz wrote: > I think I saw a comment under this thread that shipping the Qt libraries > to make a self-contained windows installation would be excessively large > (350 MB from my memory). This probably is far more than is necessary > simply to use the qt devices. We ship binaries of our QSAS application > for windows with all the necessary qt libraries. At rough calculation > the qt dll's take up about 17 MB. (our entire application is zipped into > 38 MB). Of course, if the use wants to build a qt application they'll > need the full Qt sdk, but to be able to drive the qt device only > requires a handful of dll's. Alban may/will be better able to advise, > but it must be straightforward to work out what libs the qt device > actually loads. The ldd application lists all shared libraries that are specifically linked directly or indirectly for a shared object. Therefore, I was able to make a different estimate based on ldd results: software@raven> ldd drivers/qt.so |grep Qt |sort libQtCore.so.4 => /home/software/qtsdk-2009.02/qt/lib/libQtCore.so.4 (0x00007fd1203b8000) libQtGui.so.4 => /home/software/qtsdk-2009.02/qt/lib/libQtGui.so.4 (0x00007fd121cfb000) libQtSvg.so.4 => /home/software/qtsdk-2009.02/qt/lib/libQtSvg.so.4 (0x00007fd122941000) libQtXml.so.4 => /home/software/qtsdk-2009.02/qt/lib/libQtXml.so.4 (0x00007fd120813000) (libplplotqtd.so and plplot_pyqt4.so produced identical results.) Here are the sizes of those four libraries (as given by ls -lh). -rwxr-xr-x 1 software software 20M 2009-04-23 09:34 libQtCore.so.4.5.1 -rwxr-xr-x 1 software software 95M 2009-04-23 09:34 libQtGui.so.4.5.1 -rwxr-xr-x 1 software software 3.9M 2009-04-23 09:34 libQtSvg.so.4.5.1 -rwxr-xr-x 1 software software 1.6M 2009-04-23 09:34 libQtXml.so.4.5.1 The 120MB total size for these four libraries is about one third the total size of libraries in /home/software/qtsdk-2009.02/qt/lib/ (the library directory of the downloaded and installed Qt SDK on my system), but still a factor of ~four larger than your estimate. I double-checked with nm that qt.so directly needs symbols defined in libQtGui.so.4.5.1 (the library that weighs in at 95MB). The same is also true for libplplotqtd.so and plplot_pyqt4.so. Of course, my estimate is based on the Linux situation which uses X to support GUIs, and it is well known that Qt uses entirely different system libraries (and presumbably a different Qt library) to support their Windows GUIs. So that may explain the difference in our estimates. Anyhow, it appears to me to require non-trivial effort (and probably on-going maintenance) to pick out the subset of Qt that you actually need for each platform where you are going to have a binary release and the result is still quite large for at least some platforms (e.g., Linux). Thus, I think the best thing to do is to ask users to download and install the Qt SDK for themselves if they want to use any of the Qt-based devices. Of course that (compressed) download is 350MB, and the corresponding installation expands it to 970MB. But that amount of download bandwidth and disk size is not that large in today's environment of 1 Megabyte/second (n.b., not Megabit/second!) download rates and 500GB disks for entry-level PC's. (And, yes, 1 Megabyte/second is what I am getting for downloads to my home computer these days now that my cable company has improved their local infrastructure. That is a huge improvement over the 100KB/second bandwidth they were delivering last year, and the fees have not gone up at all!) Of course, when you expand the argument to pango/cairo (and other external libraries) it makes more and more sense to ask the users to be completely responsible for the non-PLplot libraries that are required for the various PLplot components that they want. (Of course, the caveat there is the work required of Hazen to document what external libraries are needed for each component of PLplot, but if he starts by just documenting qt and cairo that already gives the PLplot binary distribution consumer a large number of choices for interactive and file devices as well as support for GUI applications using the qt and cairo "external" devices.) I also have a comment regarding Werner's scripting suggestion. I would separate out some of that functionality and replace others. To be specific, if you have a CMake-based method of building wxwidgets, then I would submit that upstream to wxwidgets (if they are interested) and also publish it in our wiki with instructions about how to use it. And similarly for any other external libraries/environments needed by PLplot where you have implemented a build system. Then the documentation of our binary release put together by Hazen could simply refer for example to that documentation if the user was interested in wxwidgets, and the places to download binary versions of qt and cairo, if the user was interested in those devices I would also replace the part of your script that is used to generate a binary distribution of PLplot since that just duplicates CPack functionality. Of course, CPack wasn't working at the time you first put the script together years ago so I understand why you did this, but I far prefer that Hazen get the CPack binary distribution functionality working since that supports zip and also many other packaging formats which we might find useful for our future 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); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Steve S. <s.s...@im...> - 2009-07-25 19:14:22
|
Hi Alan, > Here are the sizes of those four libraries (as given by ls -lh). > > -rwxr-xr-x 1 software software 20M 2009-04-23 09:34 libQtCore.so.4.5.1 > -rwxr-xr-x 1 software software 95M 2009-04-23 09:34 libQtGui.so.4.5.1 > -rwxr-xr-x 1 software software 3.9M 2009-04-23 09:34 libQtSvg.so.4.5.1 > -rwxr-xr-x 1 software software 1.6M 2009-04-23 09:34 libQtXml.so.4.5.1 > > The 120MB total size for these four libraries is about one third the total > size of libraries in /home/software/qtsdk-2009.02/qt/lib/ (the library > directory of the downloaded and installed Qt SDK on my system), but still a > factor of ~four larger than your estimate. I double-checked with nm that > qt.so directly needs symbols defined in libQtGui.so.4.5.1 (the library that > weighs in at 95MB). The same is also true for libplplotqtd.so and > plplot_pyqt4.so. Of course, my estimate is based on the Linux situation > which uses X to support GUIs, and it is well known that Qt uses entirely > different system libraries (and presumbably a different Qt library) to > support their Windows GUIs. So that may explain the difference in our > estimates. Hmmm. Here are the same 4 libs from my linux machine (I installed these; the version corresponding to my suse 10.2 operating system is far older): qt_sdk/lib> ls -lh -rwxr-xr-x 1 sjs users 2.7M 2009-04-22 13:19 libQtCore.so.4.5.1 -rwxr-xr-x 1 sjs users 12M 2009-04-22 13:19 libQtGui.so.4.5.1 -rwxr-xr-x 1 sjs users 409K 2009-04-22 13:19 libQtSvg.so.4.5.1 -rwxr-xr-x 1 sjs users 347K 2009-04-22 13:19 libQtXml.so.4.5.1 which totals 15 MB so I'm a little perplexed. (the only obvious thing I can think of is that I run a 32-bit system and perhaps you are working on a 64-bit one but I'd naively expect that to introduce at worst a factor of 2 and not nearly 10. The sdk downloads are 275 and 353 MB respoectively) Of more relevance here, though, are the size of the Windows .dll's. Here are the same 4 from my windows box (as shipped by us with QSAS). This is the output from the dir command, which reports the entire directory as 15 File(s) 21,146,566 bytes so for sure these are in bytes(!). 02/12/2008 11:07 2,662,912 QtCore4.dll 27/09/2008 11:00 10,424,832 QtGui4.dll 27/09/2008 11:15 411,136 QtSvg4.dll 27/09/2008 10:38 505,344 QtXml4.dll which is only 14 MB. We ship a couple more dll's, namely 27/09/2008 11:06 3,415,040 Qt3Support4.dll 27/09/2008 10:41 1,248,256 QtNetwork4.dll 27/09/2008 11:00 304,640 QtSql4.dll but these are probably needed for the rest of our qt application. I don't know which version of qt these are, but I think they are probably 4.5. Enjoy the rest of the weekend... Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7900 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 711A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2009-07-25 20:16:00
|
On 2009-07-25 20:14+0100 Steve Schwartz wrote: > Hi Alan, > >> Here are the sizes of those four libraries (as given by ls -lh). >> >> -rwxr-xr-x 1 software software 20M 2009-04-23 09:34 libQtCore.so.4.5.1 >> -rwxr-xr-x 1 software software 95M 2009-04-23 09:34 libQtGui.so.4.5.1 >> -rwxr-xr-x 1 software software 3.9M 2009-04-23 09:34 libQtSvg.so.4.5.1 >> -rwxr-xr-x 1 software software 1.6M 2009-04-23 09:34 libQtXml.so.4.5.1 >> > > Hmmm. Here are the same 4 libs from my linux machine (I installed these; > the version corresponding to my suse 10.2 operating system is far > older): > > qt_sdk/lib> ls -lh > -rwxr-xr-x 1 sjs users 2.7M 2009-04-22 13:19 libQtCore.so.4.5.1 > -rwxr-xr-x 1 sjs users 12M 2009-04-22 13:19 libQtGui.so.4.5.1 > -rwxr-xr-x 1 sjs users 409K 2009-04-22 13:19 libQtSvg.so.4.5.1 > -rwxr-xr-x 1 sjs users 347K 2009-04-22 13:19 libQtXml.so.4.5.1 > > which totals 15 MB so I'm a little perplexed. (the only obvious thing I > can think of is that I run a 32-bit system and perhaps you are working > on a 64-bit one yes... > but I'd naively expect that to introduce at worst a > factor of 2 and not nearly 10. I agree it seems unlikely that the size difference is due to 64 bit versus 32 bit. To confuse issues some more, the size of the older system version of libQtGui on my 64-bit system is -rw-r--r-- 1 root root 9.4M 2008-09-29 16:23 /usr/lib/libQtGui.so.4.4.3 I wonder if this factor of 10 size difference between the two 64-bit versions on my machine is due to the system one being stripped and the downloaded one not being stripped? Anyhow, the basic point still remains that the required Qt libraries are not small under all circumstances. If it is something as simple as stripping, that still adds an additional headache (finding Qt libraries to distribute that are stripped). Getting into the _complete_ binary distribution business is hard for something like PLplot with all its dependencies. Hazen, I would advise avoiding all that pain by sticking with just distributing a binary version of PLplot without the external dependencies. That is hard enough already because I just realized you are going to have to think carefully about the 64-bit versus 32-bit issue. I notice, for example, that on the Qt binary download page there are 64-bit and 32 bit Linux versions but no such separation for Mac OS X and Windows. It's quite possible that means those OS's deal with 32-bit versus 64-bit automagically. OTOH, there may be an assumption or de facto standard that all binary distributions for those OS's are 32-bit. I don't know. BTW, I think there has been an attempt by some Linux distributions to support mixed 32-bit and 64-bit systems. I don't know whether that effort is continuing, but I am very happy with my pure 64-bit system for Debian, and I wouldn't want the heachaces of mixing in some 32-bit apps and libraries. 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 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: Alan W. I. <ir...@be...> - 2009-07-26 02:20:52
|
On 2009-07-25 13:15-0700 Alan W. Irwin wrote: > I wonder if this factor of 10 size difference between the two 64-bit > versions on my machine is due to the system one being stripped and > the downloaded one not being stripped? As an experiment I tried the following: irwin@raven> strip -o /tmp/gui.so ~software/qtsdk-2009.02/qt/lib/libQtGui.so.4.5.1 irwin@raven> ls -lh /tmp/gui.so ~software/qtsdk-2009.02/qt/lib/libQtGui.so.4.5.1 -rwxr-xr-x 1 software software 95M 2009-04-23 09:34 /home/software/qtsdk-2009.02/qt/lib/libQtGui.so.4.5.1* -rw-r--r-- 1 irwin irwin 11M 2009-07-25 19:13 /tmp/gui.so That certainly solves the size disparity mystery, but I am amazed that stripping makes that much of a difference. Live and learn. 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 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: Werner S. <sm...@ia...> - 2009-07-26 08:10:58
|
Hi Alan, > > Hazen, I would advise avoiding all that pain by sticking with just > distributing a binary version of PLplot without the external > dependencies. Nope, not a good idea. Although most dlls are loaded on demand (with the driver dll) it's just not the way a Windows user wants to have a binary of a library. So you would provide a binary which is just broken, since dll dependencies are missing. You await that the user is downloading 6 other libraries on its own, just to make plplot work. Sorry, but Windows is working different. There is not apt-get or yum which just solves these dependency issues for you. I would just provide a binary which has everything in it (this is what is "usual" in the windows world). E.g. the QT SDK provides lot of libraries which are not by Qt/Nokia (e.g. libpng, webkit and dozens others). They don't assume, that you compile webkit on your own (which is close to impossible ;). We could provide several plplot distributions, e.g. one which has only the wingcc driver in and all other devices which are easy to compile (png, svg, ect.) and one heavy binary with qt and others. And exactly here is the point where my script comes in handy. To answer you earlier message, cpack would be perfect, but you need to copy the necessary dlls in afterwards into the zip file. But Cpack doesn't compile other dependencies. And actually my script is not about to replace cpack. The aim of the script is to provide a "standard" development environment where all libraries are downloaded and compiled with known parameters. Then plplot is compiled and cpack can be used to make the package. The script can then copy the missing dlls into the zip. I know this is completely different to Linux, but in Linux one has problems with a certain library you ask him which version he has and if he used apt-get. If Hazen compiles the qhull library and uses it and after one year I have problem with that library and I ask him how he compiled the library, he may not know. It may even a problem with two or more version of the same library being available on the same system (which happens often) and then you use the wrong library without knowing that. Using a script you provide all the libraries and you are *sure* that these libraries are used. I'm feeling quite strong about that issue, since I had all these problems the last 10 years I developed on Windows machines, and such scripts I use often in my projects and made my life much easier especially working with other developers, since they then use also the same "standard" development environment. Werner > That is hard enough already because I just realized you are going to > have to > think carefully about the 64-bit versus 32-bit issue. I notice, for > example, that on the Qt binary download page there are 64-bit and 32 > bit > Linux versions but no such separation for Mac OS X and Windows. > It's quite > possible that means those OS's deal with 32-bit versus 64-bit > automagically. > OTOH, there may be an assumption or de facto standard that all binary > distributions for those OS's are 32-bit. I don't know. > > BTW, I think there has been an attempt by some Linux distributions to > support mixed 32-bit and 64-bit systems. I don't know whether that > effort > is continuing, but I am very happy with my pure 64-bit system for > Debian, > and I wouldn't want the heachaces of mixing in some 32-bit apps and > libraries. > > 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 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 > __________________________ -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 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...> - 2009-07-26 17:45:15
|
On 2009-07-26 10:10+0200 Werner Smekal wrote: > Hi Alan, >> >> Hazen, I would advise avoiding all that pain by sticking with just >> distributing a binary version of PLplot without the external dependencies. > > Nope, not a good idea. Although most dlls are loaded on demand (with the > driver dll) it's just not the way a Windows user wants to have a binary of a > library. So you would provide a binary which is just broken, since dll > dependencies are missing. You await that the user is downloading 6 other > libraries on its own, just to make plplot work. Sorry, but Windows is working > different. There is not apt-get or yum which just solves these dependency > issues for you. I would just provide a binary which has everything in it > (this is what is "usual" in the windows world). E.g. the QT SDK provides lot > of libraries which are not by Qt/Nokia (e.g. libpng, webkit and dozens > others). They don't assume, that you compile webkit on your own (which is > close to impossible ;). We could provide several plplot distributions, e.g. > one which has only the wingcc driver in and all other devices which are easy > to compile (png, svg, ect.) and one heavy binary with qt and others. I trust your judgement about what seems normal in the Windows culture, but in my opinion that culture has to change if free software is ever to get anywhere in the Windows world since the "complete" packages are much larger than the have to be. I guess the only way to overthrow this Windows "complete package" culture is to have self-consistent software distributions on Windows like there are on Linux. Cygwin is obviously one example of this, and there are others in a much less complete state such as the mingwPORT effort (http://www.mingw.org/wiki/mingwPORT) and the gnuwin32 effort (http://gnuwin32.sourceforge.net/). Given this situation, one of our binary distribution priorities should be to get PLplot into at least Cygwin. There are all sorts of plotting packages there (including our principal competitor gnuplot), but no PLplot, yet. It would have to be a light-weight version of PLplot without qt, cairo, or wxwidgets (since Qt4, libpango/libcairo, and wxwidgets packages do not exist for Cygwin), but that would at least give Cygwin users an additional good plotting option. So I hope either you or Arjen (our two software developers with current Cygwin experience) of Hazen (who appears to be just getting into Windows) volunteers to be the Cygwin maintainer of PLplot. If in addition we are going to get into the complete binary package business for Windows, I agree with your point above about having both a light-weight and heavy-weight version. > And > exactly here is the point where my script comes in handy. To answer you > earlier message, cpack would be perfect, but you need to copy the necessary > dlls in afterwards into the zip file. But Cpack doesn't compile other > dependencies. And actually my script is not about to replace cpack. The aim > of the script is to provide a "standard" development environment where all > libraries are downloaded and compiled with known parameters. > A separate script would be great to download and build all external libraries that are needed. Once all the dlls were assembled that way by the script, then I would suggest either the script copy them to what will become the install tree before the PLplot build and install or using the CMake install command (guarded by appropriate logic so this only happens when creating a complete binary package for Windows) to copy those dlls into the install tree. CPack just packages up what is in the install tree when creating a binary software package so if you use either of those two alternatives for copying the dlls into the install tree before CPack is run, you would not have to copy the dlls into place after CPack is run (which means you won't have to unpack the binary package, copy to its tree, and repack it again). BTW, one complication of the above "complete binary package" model is you must follow the licensing provisions. That means for LGPL software like pango/cairo and Qt you cannot distribute dll's without also making the source code available. It doesn't have to be part of the binary package, but you do have to provide an equivalent source package (such as RedHat's source rpms that correspond to their binary rpms). There has been a case in the last year where it was proved not enough to simply point to some external site where the source code was available. You have to make GPL and LGPL software source available yourself (like RedHat and all Linux distros do), and there is no way I want PLplot to be even close to any violation of a free software license. I agree with you that complete light-weight and heavy-weight binary package of PLplot will probably be popular on Windows, but in that case you are stuck with the source redistribution of the external (L)GPLed packages as well. However, you might also want to consider an additional option of a "no_external" binary package for PLplot which installs no external libraries, but instead gives the users the above script to build what they need. That option does not require external source distribution since you are not distributing external dll's in that case. Probably most users would prefer the "complete" light-weight or heavy-weight packages (at least to start), but the no_external package costs little to produce compared to the others, and its popularity (as measured by SF download statistics) might surprise us. 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 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: Werner S. <sm...@ia...> - 2009-08-08 11:25:47
|
Hi Alan, > > I trust your judgement about what seems normal in the Windows > culture, but > in my opinion that culture has to change if free software is ever to > get > anywhere in the Windows world since the "complete" packages are much > larger than the have to be. > > I guess the only way to overthrow this Windows "complete package" > culture is > to have self-consistent software distributions on Windows like there > are on > Linux. Cygwin is obviously one example of this, and there are > others in a > much less complete state such as the mingwPORT effort > (http://www.mingw.org/wiki/mingwPORT) and the gnuwin32 effort > (http://gnuwin32.sourceforge.net/). Sure, but Windows is not POSIX OS and it's difficult to port all the programs. gnuwin32 and mingwPORT don't cover everything just some selected programs and cygwin has other disadvantages (e.g. doesn't "fit" well into windows. It's a good idea many people had before (apt- get would be great for Windows) but we won't be able to change that. > > Given this situation, one of our binary distribution priorities > should be to > get PLplot into at least Cygwin. There are all sorts of plotting > packages > there (including our principal competitor gnuplot), but no PLplot, > yet. It > would have to be a light-weight version of PLplot without qt, cairo, > or > wxwidgets (since Qt4, libpango/libcairo, and wxwidgets packages do > not exist > for Cygwin), but that would at least give Cygwin users an additional > good > plotting option. So I hope either you or Arjen (our two software > developers > with current Cygwin experience) of Hazen (who appears to be just > getting into Windows) volunteers to be the Cygwin maintainer of > PLplot. I already had a look into this months ago, but it's not "straight- forward". But I agree 100% with you, that this is a necessary step to take. People who want to try out plplot likely might have experiences with cygwin already and installing plplot with cygwin would just be a "piece-of-cake". I hope that I can make such a port anytime in the future (if somebody else does that the better). > > If in addition we are going to get into the complete binary package > business > for Windows, I agree with your point above about having both a light- > weight > and heavy-weight version. > >> And >> exactly here is the point where my script comes in handy. To answer >> you >> earlier message, cpack would be perfect, but you need to copy the >> necessary >> dlls in afterwards into the zip file. But Cpack doesn't compile >> other >> dependencies. And actually my script is not about to replace cpack. >> The aim >> of the script is to provide a "standard" development environment >> where all >> libraries are downloaded and compiled with known parameters. >> > > A separate script would be great to download and build all external > libraries that are needed. Once all the dlls were assembled that > way by the > script, then I would suggest either the script copy them to what > will become > the install tree before the PLplot build and install or using the > CMake > install command (guarded by appropriate logic so this only happens > when > creating a complete binary package for Windows) to copy those dlls > into the > install tree. CPack just packages up what is in the install tree when > creating a binary software package so if you use either of those two > alternatives for copying the dlls into the install tree before CPack > is run, > you would not have to copy the dlls into place after CPack is run > (which > means you won't have to unpack the binary package, copy to its tree, > and > repack it again). Good idea. maybe not installing all the packages into the install tree, because this would make the package huge, but only the dlls. > > BTW, one complication of the above "complete binary package" model > is you > must follow the licensing provisions. That means for LGPL software > like > pango/cairo and Qt you cannot distribute dll's without also making the > source code available. It doesn't have to be part of the binary > package, > but you do have to provide an equivalent source package (such as > RedHat's > source rpms that correspond to their binary rpms). There has been a > case in > the last year where it was proved not enough to simply point to some > external site where the source code was available. You have to make > GPL and > LGPL software source available yourself (like RedHat and all Linux > distros > do), and there is no way I want PLplot to be even close to any > violation > of a free software license. I know, but as you say, you just need to provide a link to the source packages. We could upload the packages on my webpage where the wiki is - this is also the way I want to go for the script - downloading source code from this webpage, since links might change which would break the script. This way we provide the source code for the script and also not to violate licenses. > > I agree with you that complete light-weight and heavy-weight binary > package > of PLplot will probably be popular on Windows, but in that case you > are > stuck with the source redistribution of the external (L)GPLed > packages as > well. However, you might also want to consider an additional option > of a > "no_external" binary package for PLplot which installs no external > libraries, but instead gives the users the above script to build > what they > need. That option does not require external source distribution > since you > are not distributing external dll's in that case. Probably most > users would > prefer the "complete" light-weight or heavy-weight packages (at > least to > start), but the no_external package costs little to produce compared > to the > others, and its popularity (as measured by SF download statistics) > might > surprise us. Regards, Werner > > 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 libLASi project (unifont.org/lasi); the > Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 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: James D. <ji...@di...> - 2009-07-29 03:25:39
|
Hazen Babcock wrote: > I'd like to start offering a Windows binary and/or an installer along > with our source releases. I now have access to a Windows box which I can > put pretty much anything on to, i.e. Qt, WxWidgets, Cairo(?), etc... so > I'm volunteering myself to generate whatever binaries needs to be > generated to make this happen. This has come up several times in the > past and then died off so I'm not really sure where things stand. So, to > start, what needs to be done to provide a minimalist version of PLplot > with the basic windows drivers (wingcc?) with working C examples? Do we > need to provide both MinGW and Visual Studio versions of the dlls? > > I think an official looking Windows installer might be a nice feature > and I was looking at WiX (http://wix.sourceforge.net/) as one option. > Any suggestions here? Or is what we are installing simple enough so that > a .zip file is sufficient and we shouldn't bother with an installer? > > -Hazen > > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > > I have been offering (updated very irregularly--I last built it last year) a windows binary version (http://dishaw.org/plplot/). In order to keep it small, I did not incorporate Qt and kept it pretty minimal in features. I also started writing a better driver for the MS Windows platform. The problem, as I see it (and it may have been fixed in the current trunk) is I had to modify the CMakefiles in order to build a library independent version of the PLplot library. A library independent version allows the programmer the flexibility on which C library is used as there are four different libraries in Visual C (static, static with debug, multithreaded, multithreaded with debug). Without a library independent version, the binary package will have to contain four different versions in order to get linking to work. I can try the latest SVN trunk to see if it builds the libraries correctly. If it doesn't, I am willing to work with a better practitioner of CMake to incorporate the necessary changes. |