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 |