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
__________________________
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
