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:
softw...@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
__________________________
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
