On 2006-12-30 11:44+0100 Werner Smekal wrote:
> Hi,
>
> since it's especially for Windows more and more complicated to have all
> 3rd party libraries included in the plplot library I would propose the
> following solution.
>
> We make an additional 3rd party library package, which contains the
> source files, header files and a custom CMakeLists.txt of all libraries
> we want to include (agg, freetype, libharu, cd, qhull,...). The
> structure would look like this:
>
> plplot
> ----> lib
> -->agg2.4
> ---->CMakeLists.txt
> ---->src
> ---->include
> -->cd1.3
> etc.
>
> The maintainance of this package would not be much effort, since we
> wouldn't need to always include the newest version of a library - it's
> just libraries known to work with plplot. And some libraries (qhull,cd)
> aren't updated anyway.
>
> Than we would need to change the Findxxx.cmake files a little bit:
>
> e.g. FindCD.cmake:
>
> find_path(CD_INCLUDE_DIR cd.h /usr/local/include /usr/include)
>
> if(CD_INCLUDE_DIR)
> [...]
> else(CD_INCLUDE_DIR)
> # library not found, see if user installed 3rd party package
> find_path(CML_DIR CMakeLists.txt ${CMAKE_SRC_DIR}/lib/cd1.3)
> if(CML_DIR)
> # yes?, so we compile it on our own
> subdirectory(CML_DIR)
> set(CD_INCLUDE_PATH ...)
> [...]
> endif(CML_DIR)
> endif(CD_INCLUDE_DIR)
> [...]
>
> This script won't work exactly like that, but you get the idea. This
> would have several advantages:
>
> 1) Very easy than for Windows users
> 2) if the system provides the libraries, we don't compile it on our own
> 3) if the user provides newer libraries, we don't compile it on our own
> 4) we have complete control of the library (shared, static, debug etc.)
> 5) Do get most features of plplot, you have only to untar the 3rd party
> package and you're ready
> 6) For users who don't use the 3rd party package there is no change at all
>
> disadvantage:
> 1) Maintain the package, but I think it's really low effort as soon as
> it is setup.
> 2) gd and wxwidgets can't be included that way.
>
> What do you think?
If you are willing to take on the responsibility of preparing and
maintaining a separate 3rd-party library source package release (presumably
a zip file) which you would separately release at our SourceForge file
release area and which the the windows user would unzip on top of their
PLplot source tree for an integrated 3rd-party and PLplot build, then that
would be fine with me.
However, I have just been struck with an alternative idea that might be even
better; make the 3rd-party build completely independent of PLplot and
provide not only a 3rd-party source release but also a binary release (which
keeps the 3rd-party libraries out of the PLplot binary release, although
they would have a common install location). The reason why I suggest this
alternative is I am a strong believer in the Unix philosophy that separate
is beautiful and over-integration can cause problems. For example, with the
original integrated build proposal, the user can really screw up if they
unzip the 3rd-party source package into the wrong location.
Note, the idea of a separate 3rd-party build and binary release is only a
possibility that I want to draw to your attention, and if you (and Arjen)
feel the integrated 3rd-party and PLplot build approach and binary release
for windows users will be easier to support, than I am willing to go along
with it since you will be the ones doing that support. :-)
By the way, when you prepare the 3rd-party source release, I assume you will
personally download the 3rd-party source code version that you want to
include in the release rather than attempting to maintain that 3rd-party
source code as part of our CVS. However, its fine with me if you maintain
the CMake infrastructure (CMakeList.txt files, etc.) for the 3rd-party
software as part of our CVS (like you do now in cmake/external for some of
the 3rd-party 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 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
