Hi Chris:
On 2011-04-16 17:45-0400 chm wrote:
> I was able to build the current plplot trunk
> from svn on cygwin 1.7.7 with some hand-holding:
> (1) First disable problem options and ones I don't think I needed to get
> started:
cmake -DCMAKE_INSTALL_PREFIX=install -DENABLE_tk=OFF
-DENABLE_tcl=OFF \
-DCMAKE_VERBOSE_MAKEFILE=ON -DBUILD_TEST=ON -DENABLE_ada=OFF \
-DENABLE_d=OFF -DENABLE_java=OFF -DENABLE_ocaml=OFF
-DENABLE_octave=OFF \
-DENABLE_cairo=OFF -DDEFAULT_NO_CAIRO_DEVICES=ON ../ 2>&1 | tee
plplot-cmake-log.txt
> (2) I had to add directories containing the cygXXX.dll files
> to the PATH in order for the build to complete. cygwin,
> being a windows systems, follows windows rules for the
> shared library DLLs. The key is that the DLL must be
> in the same directory or in the PATH to be found. It also
> needs to be set as executable. The directories with DLLs
> were:
>
> <build-dir>/bindings/c++
> <build-dir>/bindings/f77
> <build-dir>/bindings/f95
> <build-dir>/bindings/qt_gui
>
> <build-dir>/lib/csa
> <build-dir>/lib/nn
> <build-dir>/lib/qsastime
>
> <build-dir>/src
>
> If all the above were temporarily added to the PATH
> before the make, that should work ok. These missing
> PATH directories typically showed in the tests, e.g.,
>
> cd buildcygwin/drivers && ./test-drv-info.exe xwin
This issue is taken care of properly on MinGW/MSYS by placing all the
dll's in the dll subdirectory of the top-level build tree. I note the
following logic in our top-level CMakeLists.txt file to implement this.
# in windows all created dlls are gathered in the dll directory
# if you add this directory to your PATH all shared libraries are
available
if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
What happens if you drop the "AND NOT CYGWIN" from the if and endif
statements? (CMake sets both WIN32 and CYGWIN to be true on the
Cygwin platform.) I think you will find all relevant dll's collected
in the dll subdirectory. After that, you get access to everything in
the build tree by simply putting that directory on your PATH.
>
>
> (3) After the install, the following two (at least)
> directories below need to be added the PATH for
> the plplot examples to run:
>
> <install-dir>/bin
> <install-dir>/lib/plplot5.9.7/driversd
The first one is generally a requirement on Linux as well so adding an
additional one for the drivers on Windows should not be too
inconvenient.
> The secret for cygwin cmake and autoconf detection is
> to make sure you don't check for win32 stuff if you
> have decided to do a unix build. Also, the compile
> and link option decisions need to allow for the fact
> that although a cygwin system does have a windows.h
> file, the build should be unix-ish.
Yes, I have heard on the CMake list that most cross-platform
Linux/Windows projects build most reliably on Cygwin if you simply
replace all "WIN32" logic with "WIN32 AND NOT CYGWIN" (with the
obvious exception of cmake build-system logic like the above where you
want the dll's that are built to be treated in a windows-like way for
collecting them so they are easier to put on the PATH).
>
> Now that I've got the plplot building [...]
I suggest you test it as well. That is most easily done by using the
-DBUILD_TEST=ON cmake option, and running the test_noninteractive and
test_interactive targets in the build tree, e.g.,
make VERBOSE=1 test_noninteractive >& make_testnon.out
make VERBOSE=1 test_interactive >& make_test.out
That captured output will have a lot of useful information for us if
anything goes wrong. Note, also that test_interactive target does
what it says so you will see lots of PLplot GUI's coming and going on
your screen. (The test is set up with the PLplot nopause option to
minimize the user intervention that is required to move through the
various interactive examples.)
> , I'm going to
> see if I can get it to talk to perl/PDL. I think
> that would be easier if I did not use dynamic drivers
> to reduce possible issues that could arise.
>
> Is there some way to build a static plplot with all the
> drivers linked in statically as well? That should
> simplify the next steps.
The dll approach can be made reasonably convenient on Cygwin as well
(see the above suggestion for changing the CMake logic so the dll's
are collected in one subdirectory of the build tree), and that is
certainly the best-tested version of our software and has the big
advantage of keeping drivers completely divorced from our principal
library. However, if you want to try the static library (+ nondynamic
driver) approach where the driver code is lumped into our core (now
static) library rather than living separately, then I suggest you try
the -DBUILD_SHARED_LIBS=OFF cmake option.
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
__________________________
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
