From: Thomas S. <th...@ws...> - 2009-02-26 00:19:34
|
Hi, I just signed up to the list, so my apologies if my post is completely out of whack. -Firstly the documentation (wiki & INSTALL) use a file named plplot_cmake. This file is not present in either 5.9.2 source tree nor the current svn trunk. I think the file I need is this one called "CMakeLists.txt". Moving on... -After running cmake in "build_dir" the makefile is created in '../' (the source dir) instead of './'. Moving on.. My real question is that there appears to be no way to tell cmake what my cairo and pangocairo build flags need to be, resulting in predictable errors such as: ...plplot-5.9.2/drivers/cairo.c:33:19: error: cairo.h: No such file or directory ...plplot-5.9.2/drivers/cairo.c:34:30: error: pango/pangocairo.h: No such file or directory Of course what is missing is these calls somewhere: $ pkg-config --cflags --libs cairo $ pkg-config --cflags --libs pangocairo Any help pointing me in the right direction would be much appreciated. Here is my cmake line: cmake -DCMAKE_INSTALL_PREFIX=/home/thomas/ -DPLD_extcairo=ON -DENABLE_f77=OFF -DENABLE_wxwidgets=OFF -DENABLE_cxx=OFF -DENABLE_python=OFF -DCMAKE_C_FLAGS=-O2 -DPLD_pscairo=OFF -DPLD_pdfcairo=OFF -DPLD_pngcairo=OFF -DPLD_xcairo=OFF -DPLD_svgcairo=OFF -DPLD_memcairo=OFF -DPLD_png=OFF -DPLD_jpeg=OFF -DPLD_gif=OFF -DPLD_hp7470=OFF -DPLD_hp7580=OFF -DPLD_lj_hpgl=OFF -DPLD_xterm=OFF -DPLD_tek4010=OFF -DPLD_4010f=OFF -DPLD_tek4107=OFF -DPLD_tek4107f=OFF -DPLD_mskermit=OFF -DPLD_versaterm=OFF -DPLD_vlt=OFF -DPLD_conex=OFF -DPLD_aqt=OFF -DPLD_cgm=OFF -DPLD_dg300=OFF -DPLD_gcw=OFF -DPLD_imp=OFF -DPLD_linuxvga=OFF -DPLD_ljii=OFF -DPLD_ljiip=OFF -DPLD_mem=OFF -DPLD_ntk=OFF -DPLD_null=OFF -DPLD_pbm=OFF -DPLD_pdf=OFF -DPLD_plmeta=OFF -DPLD_ps=OFF -DPLD_pstex=OFF -DPLD_psttf=OFF -DPLD_svg=OFF -DPLD_tk=OFF -DPLD_tkwin=OFF -DPLD_wingcc=OFF -DPLD_wxwidgets=OFF -DPLD_xfig=OFF -DPLD_xwin=OFF ../CMakeLists.txt >& cmake.out and cmake.out looks like: -- Checking whether system has ANSI C header files -- ANSI C header files - found -- SWIG_VERSION = 1.3.33 -- Looking for pkg-config - found -- X11_FOUND = 1 -- X11_INCLUDE_DIR = /usr/include -- X11_COMPILE_FLAGS = -I/usr/include -- X11_LIBRARIES = /usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libX11.so;/usr/lib/libXext.so -- ENABLE_tcl is OFF so disabling everything else that is Tcl/Tk related -- FREETYPE_INCLUDE_DIR = /usr/include/freetype2 -- FREETYPE_LIBRARIES = /usr/lib/libfreetype.so -- checking for module 'pango' -- found pango, version 1.20.5 -- checking for module 'pangoft2' -- found pangoft2, version 1.20.5 -- Found LTDL: /usr/lib/libltdl.so;/usr/lib/libdl.so -- LTDL_INCLUDE_DIR = /usr/include -- LTDL_LIBRARY_DIR = /usr/lib -- LTDL_LIBRARIES = /usr/lib/libltdl.so;/usr/lib/libdl.so Summary of CMake build system results for PLplot Install location variables which can be set by the user: CMAKE_INSTALL_PREFIX: /home/thomas CMAKE_INSTALL_EXEC_PREFIX /home/thomas CMAKE_INSTALL_BINDIR /home/thomas/bin CMAKE_INSTALL_DATADIR /home/thomas/share CMAKE_INSTALL_LIBDIR /home/thomas/lib CMAKE_INSTALL_INCLUDEDIR /home/thomas/include CMAKE_INSTALL_INFODIR /home/thomas/share/info CMAKE_INSTALL_MANDIR /home/thomas/share/man Derived install location variables: DATA_DIR /home/thomas/share/plplot5.9.2 LIB_DIR /home/thomas/lib INCLUDE_DIR /home/thomas/include/plplot BIN_DIR /home/thomas/bin TCL_DIR /home/thomas/share/plplot5.9.2/tcl ADA_INCLUDE_DIR /home/thomas/share/ada/adainclude/plplotadad ADA_LIB_DIR /home/thomas/lib/ada/adalib/plplotadad PYTHON_INSTDIR DRV_DIR /home/thomas/lib/plplot5.9.2/driversd DOC_DIR /home/thomas/share/doc/plplot MAN_DIR /home/thomas/share/man INFO_DIR /home/thomas/share/info Other important CMake variables: CMAKE_SYSTEM_NAME: Linux UNIX: 1 WIN32: APPLE: MSVC: (MSVC_VERSION: ) MINGW: MSYS: CYGWIN: BORLAND: WATCOM: SWIG_FOUND: 1 PERL_FOUND: TRUE X11_FOUND: 1 CMAKE_BUILD_TYPE: CMAKE_C_COMPILER CMAKE_C_FLAGS: /usr/bin/gcc -O2 LIB_TAG: d ENABLE_DYNDRIVERS: ON DRIVERS_LIST: cairo DEVICES_LIST: extcairo Library options: BUILD_SHARED_LIBS: ON PL_DOUBLE: ON Optional libraries: HAVE_QHULL: OFF WITH_CSA: ON HAVE_FREETYPE: ON HAVE_PTHREAD: ON HAVE_AGG: OFF Language Bindings: ENABLE_f77: OFF ENABLE_f95: OFF ENABLE_cxx: OFF ENABLE_java: OFF ENABLE_python: OFF ENABLE_octave: OFF ENABLE_tcl: OFF ENABLE_itcl: OFF ENABLE_tk: OFF ENABLE_itk: OFF ENABLE_pdl: OFF ENABLE_wxwidgets: OFF ENABLE_gnome2: OFF ENABLE_pygcw: OFF ENABLE_ada: OFF ENABLE_d: ENABLE_ocaml: OFF -- Configuring done -- Generating done -- Build files have been written to: /home/thomas/src/plplot-5.9.2 |
From: Alan W. I. <ir...@be...> - 2009-02-26 01:29:13
|
On 2009-02-25 18:22-0600 Thomas Stover wrote: > Hi, I just signed up to the list, so my apologies if my post is > completely out of whack. > > -Firstly the documentation (wiki & INSTALL) use a file named > plplot_cmake. This file is not present in either 5.9.2 source tree nor > the current svn trunk. The documentation did attempt to discuss the "plplot_cmake" name used in the example, but it was a bit confusing so I have just changed those remarks to the following: Note in the above example an initially empty build directory (arbitrarily) named build_dir is used to insure a clean start, and ../plplot_cmake is the (arbitrary) name of the top-level directory of a freshly checked out source tree from our svn repository. If instead you use a freshly unpacked PLplot source distribution tarball "../plplot_cmake" will need to be replaced by "../plplot-5.9.2" (for our latest release at time of writing). I hope that clears it up for you. For a svn checkout the name of the top level directory is anything you want to specify. That's not true of an unpacked source distribution tarball (although you could mv the resulting plplot-$version directory to any arbitrary name as well). > -After running cmake in "build_dir" the makefile is created in '../' > (the source dir) instead of './'. Moving on.. That only happens if you have attempted to build in the top-level source-tree directory before. Try pristine source (freshly checked out from svn or freshly unpacked from a tarball), then try to build from a separate initially empty build_directory. All the build action is in the build tree and the source-tree should have no files written into it at all (which is a very nice property to have). > > My real question is that there appears to be no way to tell cmake what > my cairo and pangocairo build flags need to be, resulting in predictable > errors such as: > ...plplot-5.9.2/drivers/cairo.c:33:19: error: cairo.h: No such file or > directory > ...plplot-5.9.2/drivers/cairo.c:34:30: error: pango/pangocairo.h: No > such file or directory > > Of course what is missing is these calls somewhere: > > $ pkg-config --cflags --libs cairo > $ pkg-config --cflags --libs pangocairo > > Any help pointing me in the right direction would be much appreciated. Our build system (implicitly) uses pkg-config (from within CMake) to find what you need to know about building against cairo. If you have installed a development version of pangocairo and cairo in a standard location, then CMake will find it using a standard pkg-config call. From your cmake output it looks to me like pango was actually found okay. > > Here is my cmake line: > > cmake -DCMAKE_INSTALL_PREFIX=/home/thomas/ -DPLD_extcairo=ON > -DENABLE_f77=OFF -DENABLE_wxwidgets=OFF -DENABLE_cxx=OFF > -DENABLE_python=OFF -DCMAKE_C_FLAGS=-O2 -DPLD_pscairo=OFF > -DPLD_pdfcairo=OFF -DPLD_pngcairo=OFF -DPLD_xcairo=OFF > -DPLD_svgcairo=OFF -DPLD_memcairo=OFF -DPLD_png=OFF -DPLD_jpeg=OFF > -DPLD_gif=OFF -DPLD_hp7470=OFF -DPLD_hp7580=OFF -DPLD_lj_hpgl=OFF > -DPLD_xterm=OFF -DPLD_tek4010=OFF -DPLD_4010f=OFF -DPLD_tek4107=OFF > -DPLD_tek4107f=OFF -DPLD_mskermit=OFF -DPLD_versaterm=OFF -DPLD_vlt=OFF > -DPLD_conex=OFF -DPLD_aqt=OFF -DPLD_cgm=OFF -DPLD_dg300=OFF > -DPLD_gcw=OFF -DPLD_imp=OFF -DPLD_linuxvga=OFF -DPLD_ljii=OFF > -DPLD_ljiip=OFF -DPLD_mem=OFF -DPLD_ntk=OFF -DPLD_null=OFF -DPLD_pbm=OFF > -DPLD_pdf=OFF -DPLD_plmeta=OFF -DPLD_ps=OFF -DPLD_pstex=OFF > -DPLD_psttf=OFF -DPLD_svg=OFF -DPLD_tk=OFF -DPLD_tkwin=OFF > -DPLD_wingcc=OFF -DPLD_wxwidgets=OFF -DPLD_xfig=OFF -DPLD_xwin=OFF > ../CMakeLists.txt >& cmake.out There is a much easier way to turn everything off except the core library build and anything else you specify. For example, cmake -DCMAKE_INSTALL_PREFIX=/home/thomas -DDEFAULT_NO_DEVICES=ON -DDEFAULT_NO_BINDINGS=ON -DPLD_pscairo=ON ../path_to_source_tree Gives you a PLplot build with just a core library and the Cairo PostScript device, but that is all. >From your cmake output and the above commands you appeared to turn everything off except the extcairo device. I am not sure how well that works (or whether you have to do something extra to make it work). It is disabled by default so I have never tried it myself. Therefore, I suggest you build one of the other cairo devices as well to make sure you have a device that is known to work (any of pdfcairo, pngcairo, pscairo, svgcairo, or xcairo should work well). Thanks for your interest in PLplot. 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 __________________________ |
From: Thomas S. <th...@ws...> - 2009-02-27 20:40:46
|
Just to follow up. I did get it to build by not trying to take everything out except extcairo. Thanks a ton for the reply. By any chance is a cross compile from linux to win32 or win64 supported? Just for C that is. I'm all thumbs with cmake. If this has not been done before, I'll be glad to test it, if someone can give me some clue how to start. For instance I have a home built cross mingw tool chain at /opt/crosscompilers/win32/bin/i686-mingw32-X (where is X is gcc, ar, ranlib, etc) with a pkg-config file directory for the win32 cairo and such at /opt/crosscompilers/win32/mingw/lib/pkgconfig. I also have a similar working win64 tool chain. (this is rapidly becoming my exclusive approach to windows development btw) Before I go to that though, the more relevant question would be will "extcairo" work on windows? Alan W. Irwin wrote: > On 2009-02-25 18:22-0600 Thomas Stover wrote: > >> Hi, I just signed up to the list, so my apologies if my post is >> completely out of whack. >> >> -Firstly the documentation (wiki & INSTALL) use a file named >> plplot_cmake. This file is not present in either 5.9.2 source tree nor >> the current svn trunk. > > The documentation did attempt to discuss the "plplot_cmake" name used > in the > example, but it was a bit confusing so I have just changed those > remarks to > the following: > > Note in the above example an initially empty build directory > (arbitrarily) > named build_dir is used to insure a clean start, and ../plplot_cmake > is the > (arbitrary) name of the top-level directory of a freshly checked out > source > tree from our svn repository. If instead you use a freshly unpacked > PLplot > source distribution tarball "../plplot_cmake" will need to be replaced by > "../plplot-5.9.2" (for our latest release at time of writing). > > I hope that clears it up for you. For a svn checkout the name of the top > level directory is anything you want to specify. That's not true of > an unpacked source distribution tarball (although you could mv the > resulting > plplot-$version directory to any arbitrary name as well). > >> -After running cmake in "build_dir" the makefile is created in '../' >> (the source dir) instead of './'. Moving on.. > > That only happens if you have attempted to build in the top-level > source-tree directory before. Try pristine source (freshly checked > out from > svn or freshly unpacked from a tarball), then try to build from a > separate > initially empty build_directory. All the build action is in the build > tree > and the source-tree should have no files written into it at all (which > is a > very nice property to have). > >> >> My real question is that there appears to be no way to tell cmake what >> my cairo and pangocairo build flags need to be, resulting in predictable >> errors such as: >> ...plplot-5.9.2/drivers/cairo.c:33:19: error: cairo.h: No such file or >> directory >> ...plplot-5.9.2/drivers/cairo.c:34:30: error: pango/pangocairo.h: No >> such file or directory >> >> Of course what is missing is these calls somewhere: >> >> $ pkg-config --cflags --libs cairo >> $ pkg-config --cflags --libs pangocairo >> >> Any help pointing me in the right direction would be much appreciated. > > Our build system (implicitly) uses pkg-config (from within CMake) to find > what you need to know about building against cairo. If you have > installed a > development version of pangocairo and cairo in a standard location, then > CMake will find it using a standard pkg-config call. From your cmake > output > it looks to me like pango was actually found okay. > >> >> Here is my cmake line: >> >> cmake -DCMAKE_INSTALL_PREFIX=/home/thomas/ -DPLD_extcairo=ON >> -DENABLE_f77=OFF -DENABLE_wxwidgets=OFF -DENABLE_cxx=OFF >> -DENABLE_python=OFF -DCMAKE_C_FLAGS=-O2 -DPLD_pscairo=OFF >> -DPLD_pdfcairo=OFF -DPLD_pngcairo=OFF -DPLD_xcairo=OFF >> -DPLD_svgcairo=OFF -DPLD_memcairo=OFF -DPLD_png=OFF -DPLD_jpeg=OFF >> -DPLD_gif=OFF -DPLD_hp7470=OFF -DPLD_hp7580=OFF -DPLD_lj_hpgl=OFF >> -DPLD_xterm=OFF -DPLD_tek4010=OFF -DPLD_4010f=OFF -DPLD_tek4107=OFF >> -DPLD_tek4107f=OFF -DPLD_mskermit=OFF -DPLD_versaterm=OFF -DPLD_vlt=OFF >> -DPLD_conex=OFF -DPLD_aqt=OFF -DPLD_cgm=OFF -DPLD_dg300=OFF >> -DPLD_gcw=OFF -DPLD_imp=OFF -DPLD_linuxvga=OFF -DPLD_ljii=OFF >> -DPLD_ljiip=OFF -DPLD_mem=OFF -DPLD_ntk=OFF -DPLD_null=OFF -DPLD_pbm=OFF >> -DPLD_pdf=OFF -DPLD_plmeta=OFF -DPLD_ps=OFF -DPLD_pstex=OFF >> -DPLD_psttf=OFF -DPLD_svg=OFF -DPLD_tk=OFF -DPLD_tkwin=OFF >> -DPLD_wingcc=OFF -DPLD_wxwidgets=OFF -DPLD_xfig=OFF -DPLD_xwin=OFF >> ../CMakeLists.txt >& cmake.out > > There is a much easier way to turn everything off except the core library > build and anything else you specify. For example, > > cmake -DCMAKE_INSTALL_PREFIX=/home/thomas -DDEFAULT_NO_DEVICES=ON > -DDEFAULT_NO_BINDINGS=ON -DPLD_pscairo=ON ../path_to_source_tree > > Gives you a PLplot build with just a core library and the Cairo > PostScript > device, but that is all. > > From your cmake output and the above commands you appeared to turn > everything off except the extcairo device. I am not sure how well that > works (or whether you have to do something extra to make it work). It is > disabled by default so I have never tried it myself. Therefore, I suggest > you build one of the other cairo devices as well to make sure you have a > device that is known to work (any of pdfcairo, pngcairo, pscairo, > svgcairo, > or xcairo should work well). > > Thanks for your interest in PLplot. > > 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 > __________________________ -- www.thomasstover.com |
From: Werner S. <sm...@ia...> - 2009-02-27 20:54:43
|
Hi Thomas, > By any chance is a cross compile from linux to win32 or win64 supported? > Just for C that is. I'm all thumbs with cmake. If this has not been done > before, I'll be glad to test it, if someone can give me some clue how to > start. For instance I have a home built cross mingw tool chain at > /opt/crosscompilers/win32/bin/i686-mingw32-X (where is X is gcc, ar, > ranlib, etc) with a pkg-config file directory for the win32 cairo and > such at /opt/crosscompilers/win32/mingw/lib/pkgconfig. I also have a > similar working win64 tool chain. (this is rapidly becoming my exclusive > approach to windows development btw) > There are some discussions about cross compiling in the cmake mailing list (archive: http://www.mail-archive.com/cm...@cm.../). AFAIR, cmake doesn't support it by default, but it is possible. > Before I go to that though, the more relevant question would be will > "extcairo" work on windows? > I've never test extcairo, but the other cairo devices (pdfcairo, svgcairo, ...) work on Windows when using gtk for Windows. So I assume extcairo will work as well. Keep us informed, since this would be interesting. Regards, Werner > Alan W. Irwin wrote: > >> On 2009-02-25 18:22-0600 Thomas Stover wrote: >> >> >>> Hi, I just signed up to the list, so my apologies if my post is >>> completely out of whack. >>> >>> -Firstly the documentation (wiki & INSTALL) use a file named >>> plplot_cmake. This file is not present in either 5.9.2 source tree nor >>> the current svn trunk. >>> >> The documentation did attempt to discuss the "plplot_cmake" name used >> in the >> example, but it was a bit confusing so I have just changed those >> remarks to >> the following: >> >> Note in the above example an initially empty build directory >> (arbitrarily) >> named build_dir is used to insure a clean start, and ../plplot_cmake >> is the >> (arbitrary) name of the top-level directory of a freshly checked out >> source >> tree from our svn repository. If instead you use a freshly unpacked >> PLplot >> source distribution tarball "../plplot_cmake" will need to be replaced by >> "../plplot-5.9.2" (for our latest release at time of writing). >> >> I hope that clears it up for you. For a svn checkout the name of the top >> level directory is anything you want to specify. That's not true of >> an unpacked source distribution tarball (although you could mv the >> resulting >> plplot-$version directory to any arbitrary name as well). >> >> >>> -After running cmake in "build_dir" the makefile is created in '../' >>> (the source dir) instead of './'. Moving on.. >>> >> That only happens if you have attempted to build in the top-level >> source-tree directory before. Try pristine source (freshly checked >> out from >> svn or freshly unpacked from a tarball), then try to build from a >> separate >> initially empty build_directory. All the build action is in the build >> tree >> and the source-tree should have no files written into it at all (which >> is a >> very nice property to have). >> >> >>> My real question is that there appears to be no way to tell cmake what >>> my cairo and pangocairo build flags need to be, resulting in predictable >>> errors such as: >>> ...plplot-5.9.2/drivers/cairo.c:33:19: error: cairo.h: No such file or >>> directory >>> ...plplot-5.9.2/drivers/cairo.c:34:30: error: pango/pangocairo.h: No >>> such file or directory >>> >>> Of course what is missing is these calls somewhere: >>> >>> $ pkg-config --cflags --libs cairo >>> $ pkg-config --cflags --libs pangocairo >>> >>> Any help pointing me in the right direction would be much appreciated. >>> >> Our build system (implicitly) uses pkg-config (from within CMake) to find >> what you need to know about building against cairo. If you have >> installed a >> development version of pangocairo and cairo in a standard location, then >> CMake will find it using a standard pkg-config call. From your cmake >> output >> it looks to me like pango was actually found okay. >> >> >>> Here is my cmake line: >>> >>> cmake -DCMAKE_INSTALL_PREFIX=/home/thomas/ -DPLD_extcairo=ON >>> -DENABLE_f77=OFF -DENABLE_wxwidgets=OFF -DENABLE_cxx=OFF >>> -DENABLE_python=OFF -DCMAKE_C_FLAGS=-O2 -DPLD_pscairo=OFF >>> -DPLD_pdfcairo=OFF -DPLD_pngcairo=OFF -DPLD_xcairo=OFF >>> -DPLD_svgcairo=OFF -DPLD_memcairo=OFF -DPLD_png=OFF -DPLD_jpeg=OFF >>> -DPLD_gif=OFF -DPLD_hp7470=OFF -DPLD_hp7580=OFF -DPLD_lj_hpgl=OFF >>> -DPLD_xterm=OFF -DPLD_tek4010=OFF -DPLD_4010f=OFF -DPLD_tek4107=OFF >>> -DPLD_tek4107f=OFF -DPLD_mskermit=OFF -DPLD_versaterm=OFF -DPLD_vlt=OFF >>> -DPLD_conex=OFF -DPLD_aqt=OFF -DPLD_cgm=OFF -DPLD_dg300=OFF >>> -DPLD_gcw=OFF -DPLD_imp=OFF -DPLD_linuxvga=OFF -DPLD_ljii=OFF >>> -DPLD_ljiip=OFF -DPLD_mem=OFF -DPLD_ntk=OFF -DPLD_null=OFF -DPLD_pbm=OFF >>> -DPLD_pdf=OFF -DPLD_plmeta=OFF -DPLD_ps=OFF -DPLD_pstex=OFF >>> -DPLD_psttf=OFF -DPLD_svg=OFF -DPLD_tk=OFF -DPLD_tkwin=OFF >>> -DPLD_wingcc=OFF -DPLD_wxwidgets=OFF -DPLD_xfig=OFF -DPLD_xwin=OFF >>> ../CMakeLists.txt >& cmake.out >>> >> There is a much easier way to turn everything off except the core library >> build and anything else you specify. For example, >> >> cmake -DCMAKE_INSTALL_PREFIX=/home/thomas -DDEFAULT_NO_DEVICES=ON >> -DDEFAULT_NO_BINDINGS=ON -DPLD_pscairo=ON ../path_to_source_tree >> >> Gives you a PLplot build with just a core library and the Cairo >> PostScript >> device, but that is all. >> >> From your cmake output and the above commands you appeared to turn >> everything off except the extcairo device. I am not sure how well that >> works (or whether you have to do something extra to make it work). It is >> disabled by default so I have never tried it myself. Therefore, I suggest >> you build one of the other cairo devices as well to make sure you have a >> device that is known to work (any of pdfcairo, pngcairo, pscairo, >> svgcairo, >> or xcairo should work well). >> >> Thanks for your interest in PLplot. >> >> 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 >> __________________________ >> > > > -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2009-02-27 21:09:10
|
On 2009-02-27 21:54+0100 Werner Smekal wrote: > Hi Thomas, >> By any chance is a cross compile from linux to win32 or win64 supported? >> Just for C that is. I'm all thumbs with cmake. If this has not been done >> before, I'll be glad to test it, if someone can give me some clue how to >> start. For instance I have a home built cross mingw tool chain at >> /opt/crosscompilers/win32/bin/i686-mingw32-X (where is X is gcc, ar, >> ranlib, etc) with a pkg-config file directory for the win32 cairo and such >> at /opt/crosscompilers/win32/mingw/lib/pkgconfig. I also have a similar >> working win64 tool chain. (this is rapidly becoming my exclusive approach >> to windows development btw) >> > There are some discussions about cross compiling in the cmake mailing list > (archive: http://www.mail-archive.com/cm...@cm.../). AFAIR, cmake doesn't > support it by default, but it is possible. Hi Thomas: I also haven't tried cross-compiling, but I understand it is a well-supported part of CMake-2.6.x (but not 2.4.x), see http://www.cmake.org/Wiki/CMake_Cross_Compiling. If following those directions gets a cross-compiled PLplot working for you, please contribute the details so we can put them in the PLplot documentation. 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 __________________________ |
From: Thomas S. <th...@ws...> - 2009-03-02 17:34:34
|
Thanks for the input on cross compiling with cmake. Using the latest version of cmake, and the documentation I made a number of attempts to use mingw to build a win32 plplot from a linux host. By the end of the day Friday I reached the conclusion that although this is probably possible using the new cmake, almost certainly the cmake project itself would needs some tweaks. If anyone is interested I can go into the details of that. So today I try a new strategy. I'll try to make a special purpose Makefile for this, manually edited config.h etc, and see what happens. Before I go trying to get the cross compile to work, I'll try a native (linux) version first as an incremental step. This appears to be "so close", but maybe I'm still light years away. This is my runtime error for my test program (the test program runs fine with a native build via cmake): *** PLPLOT ERROR, IMMEDIATE EXIT *** Unable to either (1) open/find or (2) allocate memory for the font file Program aborted and that's not a segmentation fault which is certainly something to celebrate! Maybe someone who actually knows what the real build system is suppose to do will get this at first sight? Keep in mind, that (especially for the sake of reducing build complexity in this special case) all I'm trying to build is the C core library with extcairo. I suspect I need to change a #define or something since I'm guessing font files don't enter the picture with pangocairo / cairo? I'm on x86_64 ubuntu 8.04. I think this is all the relevant files: ====== Makefile.linux ============================================================ #experimental Makefile based mostly CC = gcc -g LIBS=`pkg-config --libs cairo pangocairo` CFLAGS = -I ./include `pkg-config --cflags cairo pangocairo glib-2.0` -DHAVE_CONFIG_H HEADERS = ./include/config.h ./include/plcore.h \ ./include/pldebug.h ./include/plDevs.h \ ./include/plplot.h ./include/plplotP.h \ ./include/plstrm.h ./include/pldll.h \ ./include/pdf.h ./include/disptab.h \ ./include/drivers.h ./include/metadefs.h \ ./lib/nn/nan.h ./include/plevent.h \ ./include/mt19937ar.h ./include/plhershey-unicode.h LIBOBJS = ./obj/cairo.o ./obj/null.o ./obj/plargs.o \ ./obj/plbox.o ./obj/plbuf.o ./obj/plcont.o \ ./obj/plcore.o ./obj/plctrl.o ./obj/plcvt.o \ ./obj/pldtik.o ./obj/plfill.o ./obj/plgridd.o \ ./obj/plhist.o ./obj/plimage.o ./obj/plline.o \ ./obj/plmap.o ./obj/plot3d.o ./obj/plpage.o \ ./obj/plsdef.o ./obj/plshade.o ./obj/plstdio.o \ ./obj/plstripc.o ./obj/plsym.o ./obj/pltick.o \ ./obj/plvect.o ./obj/plvpor.o ./obj/plwind.o \ ./obj/pdfutils.o ./obj/mt19937ar.o all: libplplot.so libcsirocsa.so test1 ./obj/csa.o : ./lib/csa/csa.c ./lib/csa/csa.h ./lib/csa/nan.h ./lib/csa/version.h $(CC) -fpic $(CFLAGS) -c ./lib/csa/csa.c -o ./obj/csa.o libcsirocsa.so : ./obj/csa.o $(CC) -shared -Wl,-soname,libcsirocsa.so -o libcsirocsa.so libplplot.so : $(LIBOBJS) libcsirocsa.so $(CC) -shared -Wl,-soname,libplplot.so -o libplplot.so $(LIBOBJS) $(LIBS) libcsirocsa.so ./obj/mt19937ar.o : ./src/mt19937ar.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/mt19937ar.c -o ./obj/mt19937ar.o ./obj/cairo.o : ./drivers/cairo.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./drivers/cairo.c -o ./obj/cairo.o ./obj/null.o : ./drivers/null.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./drivers/null.c -o ./obj/null.o ./obj/plargs.o : ./src/plargs.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plargs.c -o ./obj/plargs.o ./obj/plbox.o : ./src/plbox.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plbox.c -o ./obj/plbox.o ./obj/plbuf.o : ./src/plbuf.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plbuf.c -o ./obj/plbuf.o ./obj/plcont.o : ./src/plcont.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plcont.c -o ./obj/plcont.o ./obj/plcore.o : ./src/plcore.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plcore.c -o ./obj/plcore.o ./obj/plctrl.o : ./src/plctrl.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plctrl.c -o ./obj/plctrl.o ./obj/plcvt.o : ./src/plcvt.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plcvt.c -o ./obj/plcvt.o ./obj/pldtik.o : ./src/pldtik.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/pldtik.c -o ./obj/pldtik.o ./obj/plfill.o : ./src/plfill.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plfill.c -o ./obj/plfill.o ./obj/plgridd.o : ./src/plgridd.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plgridd.c -o ./obj/plgridd.o ./obj/plhist.o : ./src/plhist.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plhist.c -o ./obj/plhist.o ./obj/plimage.o : ./src/plimage.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plimage.c -o ./obj/plimage.o ./obj/plline.o : ./src/plline.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plline.c -o ./obj/plline.o ./obj/plmap.o : ./src/plmap.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plmap.c -o ./obj/plmap.o ./obj/plot3d.o : ./src/plot3d.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plot3d.c -o ./obj/plot3d.o ./obj/plpage.o : ./src/plpage.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plpage.c -o ./obj/plpage.o ./obj/plsdef.o : ./src/plsdef.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plsdef.c -o ./obj/plsdef.o ./obj/plshade.o : ./src/plshade.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plshade.c -o ./obj/plshade.o ./obj/plstdio.o : ./src/plstdio.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plstdio.c -o ./obj/plstdio.o ./obj/plstripc.o : ./src/plstripc.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plstripc.c -o ./obj/plstripc.o ./obj/pltick.o : ./src/pltick.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/pltick.c -o ./obj/pltick.o ./obj/plvect.o : ./src/plvect.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plvect.c -o ./obj/plvect.o ./obj/plvpor.o : ./src/plvpor.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plvpor.c -o ./obj/plvpor.o ./obj/plwind.o : ./src/plwind.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plwind.c -o ./obj/plwind.o ./obj/plsym.o : ./src/plsym.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/plsym.c -o ./obj/plsym.o ./obj/pdfutils.o : ./src/pdfutils.c $(HEADERS) $(CC) -fpic $(CFLAGS) -c ./src/pdfutils.c -o ./obj/pdfutils.o test1 : libplplot.so $(CC) -I ./include `pkg-config --cflags cairo` test1.c libplplot.so libcsirocsa.so -o test1 clean: rm -f ./obj/* rm -f libcsirocsa.so rm -f libplplot.so rm -f test1 ============ test1.c - taken from mailing list archives ================== #include <stdio.h> #include <cairo.h> #include <cairo-ps.h> #include <plplot.h> int main(int argc, char *argv[]) { cairo_surface_t *cairoSurface; cairo_t *cairoContext; cairoSurface = cairo_ps_surface_create("test.ps", 720, 540); cairoContext = cairo_create(cairoSurface); plsdev("extcairo"); plinit(); pl_cmd(PLESC_DEVINIT, cairoContext); plenv(0.0, 1.0, 0.0, 1.0, 1, 0); pllab("x", "y", "title"); plend(); cairo_destroy(cairoContext); cairo_surface_destroy(cairoSurface); return 0; } ================ config.h (total guessing) ========================= this is long so I'll post if anyone cares. |
From: Werner S. <sm...@ia...> - 2009-03-02 19:19:11
|
Hi Thomas, just for the records, since you already figured it out yourself: > *** PLPLOT ERROR, IMMEDIATE EXIT *** > Unable to either (1) open/find or (2) allocate memory for the font file > Program aborted Here, PLplot can't find the Hershey fonts, which are in the PLplot data directory. Actually this is so important, that this is so far the only entry in our FAQ ;) http://www.miscdebris.net/plplot_wiki/index.php?title=Frequently_Asked_Questions Good luck on your way to cross-compile PLplot. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2009-03-02 19:17:48
|
On 2009-03-02 11:38-0600 Thomas Stover wrote: > Thanks for the input on cross compiling with cmake. Using the latest version > of cmake, and the documentation I made a number of attempts to use mingw to > build a win32 plplot from a linux host. By the end of the day Friday I > reached the conclusion that although this is probably possible using the new > cmake, almost certainly the cmake project itself would needs some tweaks. If > anyone is interested I can go into the details of that. I think doing your own specific Makefile based build system for PLplot would work, but I also think it would take a rather large effort on your part with no beneficial networking effects at all (nobody else would use your approach so you could gain little help from anybody else or lend help to anybody else). Furthermore, developing your CMake skills is worth doing in its own right since an increasing number of projects (KDE is probably the biggest of these) use it. Therefore, I encourage you to stick with CMake a bit longer even though you are unfamiliar with it at the moment. Whatever you decide to do, cross-compilation is going to be tricky because of all the various library dependencies (mostly from PLplot device drivers, but the core PLplot library also has a few library dependencies). All the dependent libraries must be available for the "other" platform before PLplot can be built for the "other" platform. So I suggest you start with a simple PLplot cross-compile with no library dependencies, and once that works, go on from there adding dependencies in small amounts. Specifically, build just the plplot C library (with libqhull and freetype dropped to eliminate those dependencies and with no dynamic drivers to eliminate the dependence on dynamic loading libraries) and the ps device driver (which has no external dependencies). The appropriate cmake options for that build scenario are -DDEFAULT_NO_BINDINGS=ON \ -DHAVE_QHULL=OFF -DWITH_FREETYPE=OFF -DENABLE_DYNDRIVERS=OFF \ -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON Can you get that combination to work with (a) an ordinary build on Linux, (b) an ordinary build on MinGW, and (c) a cross-build on Linux for MinGW? Once you get that first simple cross-build working properly, then I think the next step is to figure out what to do with dynamic devices. That does work on MinGW so it should be straightforward to get it to work for a Linux cross-build for MinGW, but I am not familiar with the MinGW dynamic device details so someone else will have to help you there. The next step after cross-built dynamic devices work could be cross-build of cairo-based devices. A pango/cairo stack is available for MinGW Windows so extending the cross-build to use cairo devices should be straightforward. In sum, my advice is to stick with CMake (since we should be able to give you some help in that case, and CMake skill with a normal build environment and also a cross-build environment is worth developing in its own right), and take it one step at a time. Do the simplest cross-build first with no dependencies. Once that works, start adding dependencies to your cross-build in small steps until you achieve the cross-build that you desire. Good luck! 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 __________________________ |
From: Andrew R. <and...@us...> - 2009-03-03 12:49:46
|
On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote: > On 2009-03-02 11:38-0600 Thomas Stover wrote: > > > Thanks for the input on cross compiling with cmake. Using the latest version > > of cmake, and the documentation I made a number of attempts to use mingw to > > build a win32 plplot from a linux host. By the end of the day Friday I > > reached the conclusion that although this is probably possible using the new > > cmake, almost certainly the cmake project itself would needs some tweaks. If > > anyone is interested I can go into the details of that. > > I think doing your own specific Makefile based build system for PLplot would > work, but I also think it would take a rather large effort on your part with > no beneficial networking effects at all (nobody else would use your approach > so you could gain little help from anybody else or lend help to anybody > else). Furthermore, developing your CMake skills is worth doing in its own > right since an increasing number of projects (KDE is probably the biggest of > these) use it. Therefore, I encourage you to stick with CMake a bit longer > even though you are unfamiliar with it at the moment. > > Whatever you decide to do, cross-compilation is going to be tricky because > of all the various library dependencies (mostly from PLplot device drivers, > but the core PLplot library also has a few library dependencies). All the > dependent libraries must be available for the "other" platform before PLplot > can be built for the "other" platform. So I suggest you start with a simple > PLplot cross-compile with no library dependencies, and once that works, go > on from there adding dependencies in small amounts. > > Specifically, build just the plplot C library (with libqhull and freetype > dropped to eliminate those dependencies and with no dynamic drivers to > eliminate the dependence on dynamic loading libraries) and the ps device > driver (which has no external dependencies). The appropriate cmake options > for that build scenario are > > -DDEFAULT_NO_BINDINGS=ON \ > -DHAVE_QHULL=OFF -DWITH_FREETYPE=OFF -DENABLE_DYNDRIVERS=OFF \ > -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON > > Can you get that combination to work with (a) an ordinary build on Linux, > (b) an ordinary build on MinGW, and (c) a cross-build on Linux for MinGW? > > Once you get that first simple cross-build working properly, then I think > the next step is to figure out what to do with dynamic devices. That does > work on MinGW so it should be straightforward to get it to work for a Linux > cross-build for MinGW, but I am not familiar with the MinGW dynamic device > details so someone else will have to help you there. > > The next step after cross-built dynamic devices work could be cross-build of > cairo-based devices. A pango/cairo stack is available for MinGW Windows so > extending the cross-build to use cairo devices should be straightforward. > > In sum, my advice is to stick with CMake (since we should be able to give > you some help in that case, and CMake skill with a normal build environment > and also a cross-build environment is worth developing in its own right), > and take it one step at a time. Do the simplest cross-build first with no > dependencies. Once that works, start adding dependencies to your cross-build > in small steps until you achieve the cross-build that you desire. Thomas, I've now done the necessary changes to plplot to allow a cmake cross-compilation of at least the basic library. See the plplot wiki http://www.miscdebris.net/plplot_wiki/index.php?title=Main_Page for instructions. I have cross-compiled for mingw32 under linux. Note that I have not tested the resulting binaries, but the compilation progresses cleanly. It would be good if you (and others) could try this approach. The only change required was to pick up build-time executables from a native build rather than the cross-compiled build. PLplot uses these in several places to generate data / source code for the build. The current stumbling block for the cairo drivers is that they use pkg-config to get the correct paths and libraries to link in. This won't work on a cross-compiled environment unless you provide suitable pkg-config files from a cross-compiled version of cairo. This should be possible though. Andrew |
From: Thomas S. <th...@ws...> - 2009-03-03 22:19:39
|
Andrew Ross wrote: > Thomas, > > I've now done the necessary changes to plplot to allow a cmake > cross-compilation of at least the basic library. See the plplot wiki > http://www.miscdebris.net/plplot_wiki/index.php?title=Main_Page > for instructions. I have cross-compiled for mingw32 under linux. Note that I > have not tested the resulting binaries, but the compilation progresses > cleanly. It would be good if you (and others) could try this approach. The > only change required was to pick up build-time executables from a native > build rather than the cross-compiled build. PLplot uses these in several > places to generate data / source code for the build. > > The current stumbling block for the cairo drivers is that they use > pkg-config to get the correct paths and libraries to link in. This won't > work on a cross-compiled environment unless you provide suitable pkg-config > files from a cross-compiled version of cairo. This should be possible > though. > > Andrew > OK I've been at this for hours. Here is my input: -Awesome. Thanks. -I'm guessing that I need to try this with the SVN tree. I'm on rev 9667. -I think sometimes CMake does some config caching or something that gets in the way big time, and I can't figure out how to clear or disable it. What are you suppose to do? I've been just starting over again with a fresh checkout. -It took me a while to figure out the native build part. That configuration needs to match. In some variations, I also needed to run make install on the native part also. The autoconf world would call this sort of requirement the HOSTCC. Of course that has a different meaning than the old meaning of HOSTCC, add more padding to the cells in the mental health wing that is autotools. -I'm curious what NaNAware is, but I haven't found a good link explaining it. -Building example1 gives these warnings: x01c.c: In function ‘main’: x01c.c:124: warning: passing argument 3 of ‘plMergeOpts’ from incompatible pointer type x01c.c:125: warning: passing argument 2 of ‘c_plparseopts’ from incompatible pointer type -Anyway, example1 runs on my windows machine with this errorish condition: *** PLPLOT ERROR, ABORTING OPERATION *** plInitDispatchTable: Could not open drivers directory, aborting operation PLplot library version: 5.9.2 got here -- 0 Plotting Options: Enter device number or keyword: -I suppose I wasn't getting this condition with the build I did with the makefile, because I wasn't using dynamic loading. Maybe I need to copy more files over? To a specific place? -What most people who want to target win32 and win64 from mingw cross compilers do that want to use gtk (and thus cairo) is download the official "all in one" bundles from the gtk site, and unpack to their cross environment. After that they edit the .pc (package config files) to reflect the real full paths of these files on the host system. Then set the PKG_CONFIG_PATH environment variable to the collection of .pc files you need at build time. -So I went ahead and tried to get a cairo driver to work by exporting PKG_CONFIG_PATH first. That (eventually) did build just fine, but again the same runtime error over on windows. -I see you guys have a separate build system to maintain for dos, maybe a cross compile with cmake would be more maintainable. One issue is the only guides I can find on building a cross dos tool chain are pretty old. I haven't had time to try to make one yet due to nostalgia being my only motivation on that one. -Also extcairo wont work by itself. At least one other cairo based driver needs to be turned on for a successful build. Not just with cross compiles, but in general. |
From: Arjen M. <arj...@de...> - 2009-03-04 07:48:23
|
On 2009-03-03 23:23, Thomas Stover wrote: > > -I'm curious what NaNAware is, but I haven't found a good link > explaining it. Hello Thomas, NaNAware refers to one of the special "numbers" in IEEE arithmetics: NaN is the acronym of Not-a-Number, it is used to represent the result of 0.0/0.0, sqrt(-1) etc. Using such special numbers (Infinity is another one) makes the floating arithmetical system a closed system, that is: every possible combination of x, y and +,-,*,/, etc. has a value. (The upshot of that characteristic of IEEE arithmetics is that the underlying hardware does not have to raise exceptions.) One peculiar property of NaN is that it is unequal to any number, even unequal to itself: NaN != NaN. That said, NaNs can be used to represent missing values, as is done in the CSA and NN libraries. But software support for dealing with NaNs is not always obvious, hence the test for NaNs in the CMake files. (I do not know of a concise publication that explains these features and more, but with the keywords above you can probably dig up tons of stuff :)) Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Andrew R. <and...@us...> - 2009-03-04 19:37:59
|
On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote: > On 2009-03-04 10:58-0000 Andrew Ross wrote: > >> Thinking about it, get-drv-info is only extracting symbols for the installed >> drivers which are in the source code anyway. There is no reason we couldn't >> have some alternative way of doing this using cmake or some scripting which >> would not rely on compiling an executable. This would be more portable for >> cross-compiling. >> >> I think the reason it might have worked in my case (I haven't checked) is >> that both platforms were using elf format object code. No guarantees in >> general though. > > Overnight, I have had similar thoughts. I agree with your previous post the > ssh approach would not be a good general approach so let's forget it. Also, > we should note that the current get-drv-info has two tasks that it does; (1) > it checks that dynamic loading works for the plug-in, and (2) it generates > the <driver>.rc file. > > Instead of this approach, I think we should simply store those <driver>.rc > files in the drivers subdirectory of the source tree and let CMake install > them or not depending on what drivers are configured. We could then rename > get-drv-info to test-drv-info. Then test-drv-info would only be run for > normal builds (and not for cross builds) and the tests that it would do > would be (1) and (2) checking that the existing <driver>.rc file is correct. I like this approach. Going further down this route, we could also commit the generated header files to svn. The tools to build them could be kept for making updates, as we do with the Hershey fonts for example. This would eliminate build time executables altogether which is probably a good thing. > > We could also get CMake/grep/etc. to generate the <driver>.rc files using > the ":[0-9]*:" regex in driver source files, but IMO that would be overkill > and potentially fragile against future drivers using that pattern for other > purposes. Thus, I favour committing the existing generated <driver>.rc > files into our subversion repository, and hand-editing of <driver>.rc for > new device drivers. Any problems with that low-tech approach would quickly > be discovered by test-drv-info for normal builds. Agreed. Are you happy to make the changes Alan? Andrew |
From: Alan W. I. <ir...@be...> - 2009-03-04 19:57:11
|
On 2009-03-04 19:37-0000 Andrew Ross wrote: > On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote: >> On 2009-03-04 10:58-0000 Andrew Ross wrote: >> >>> Thinking about it, get-drv-info is only extracting symbols for the installed >>> drivers which are in the source code anyway. There is no reason we couldn't >>> have some alternative way of doing this using cmake or some scripting which >>> would not rely on compiling an executable. This would be more portable for >>> cross-compiling. >>> >>> I think the reason it might have worked in my case (I haven't checked) is >>> that both platforms were using elf format object code. No guarantees in >>> general though. >> >> Overnight, I have had similar thoughts. I agree with your previous post the >> ssh approach would not be a good general approach so let's forget it. Also, >> we should note that the current get-drv-info has two tasks that it does; (1) >> it checks that dynamic loading works for the plug-in, and (2) it generates >> the <driver>.rc file. >> >> Instead of this approach, I think we should simply store those <driver>.rc >> files in the drivers subdirectory of the source tree and let CMake install >> them or not depending on what drivers are configured. We could then rename >> get-drv-info to test-drv-info. Then test-drv-info would only be run for >> normal builds (and not for cross builds) and the tests that it would do >> would be (1) and (2) checking that the existing <driver>.rc file is correct. > > I like this approach. Going further down this route, we could > also commit the generated header files to svn. The tools to build > them could be kept for making updates, as we do with the Hershey > fonts for example. This would eliminate build time executables > altogether which is probably a good thing. Generally, I really dislike putting generated files into the source tree as a point of principle, but clearly cross-building is in our future, and for that scenario I think it is "needs must" for the <driver>.rc files, and I am willing to be flexible about the rest of your proposed changes as well especially if it makes cross-building much easier (i.e., eliminate the native build step altogether). > >> >> We could also get CMake/grep/etc. to generate the <driver>.rc files using >> the ":[0-9]*:" regex in driver source files, but IMO that would be overkill >> and potentially fragile against future drivers using that pattern for other >> purposes. Thus, I favour committing the existing generated <driver>.rc >> files into our subversion repository, and hand-editing of <driver>.rc for >> new device drivers. Any problems with that low-tech approach would quickly >> be discovered by test-drv-info for normal builds. > > Agreed. Are you happy to make the changes Alan? Normally, yes, but right now I am swamped with other PLplot projects. So if you have time to get to this yourself before I can (probably at least a week from now), please go ahead (including if you like the rest of the files you mentioned above that currently require an executable to built at build time to generate them). 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 __________________________ |
From: Andrew R. <and...@us...> - 2009-03-06 07:18:01
|
On Wed, Mar 04, 2009 at 07:37:53PM +0000, Andrew Ross wrote: > On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote: > > On 2009-03-04 10:58-0000 Andrew Ross wrote: > > > >> Thinking about it, get-drv-info is only extracting symbols for the installed > >> drivers which are in the source code anyway. There is no reason we couldn't > >> have some alternative way of doing this using cmake or some scripting which > >> would not rely on compiling an executable. This would be more portable for > >> cross-compiling. > >> > >> I think the reason it might have worked in my case (I haven't checked) is > >> that both platforms were using elf format object code. No guarantees in > >> general though. > > > > Overnight, I have had similar thoughts. I agree with your previous post the > > ssh approach would not be a good general approach so let's forget it. Also, > > we should note that the current get-drv-info has two tasks that it does; (1) > > it checks that dynamic loading works for the plug-in, and (2) it generates > > the <driver>.rc file. > > > > Instead of this approach, I think we should simply store those <driver>.rc > > files in the drivers subdirectory of the source tree and let CMake install > > them or not depending on what drivers are configured. We could then rename > > get-drv-info to test-drv-info. Then test-drv-info would only be run for > > normal builds (and not for cross builds) and the tests that it would do > > would be (1) and (2) checking that the existing <driver>.rc file is correct. > > I like this approach. Going further down this route, we could > also commit the generated header files to svn. The tools to build > them could be kept for making updates, as we do with the Hershey > fonts for example. This would eliminate build time executables > altogether which is probably a good thing. The only complication of this approach is what happens for drivers which support multiple devices (e.g. cairo) which can be independently turned on or off. The .rc file will change depending on options. The simple "commit the file" approach won't be adequate for this. Andrew |
From: Alan W. I. <ir...@be...> - 2009-03-06 16:11:27
|
On 2009-03-06 07:17-0000 Andrew Ross wrote: > On Wed, Mar 04, 2009 at 07:37:53PM +0000, Andrew Ross wrote: >> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote: >>> Instead of this approach, I think we should simply store those <driver>.rc >>> files in the drivers subdirectory of the source tree and let CMake install >>> them or not depending on what drivers are configured. We could then rename >>> get-drv-info to test-drv-info. Then test-drv-info would only be run for >>> normal builds (and not for cross builds) and the tests that it would do >>> would be (1) and (2) checking that the existing <driver>.rc file is correct. >> >> I like this approach. Going further down this route, we could >> also commit the generated header files to svn. The tools to build >> them could be kept for making updates, as we do with the Hershey >> fonts for example. This would eliminate build time executables >> altogether which is probably a good thing. > > The only complication of this approach is what happens for drivers > which support multiple devices (e.g. cairo) which can be independently > turned on or off. The .rc file will change depending on options. The > simple "commit the file" approach won't be adequate for this. Agreed. Taking it one step further, have <driver>.rc.full files in the source tree which have the full complement of devices for a given device driver, and let CMake parse that file (using regular expressions, not direct CMake configuration variables as in *.in files) to generate the correct <driver>.rc file in the build tree that drops the unwanted devices. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-03-11 03:07:26
|
On 2009-03-06 08:11-0800 Alan W. Irwin wrote: > On 2009-03-06 07:17-0000 Andrew Ross wrote: > >> On Wed, Mar 04, 2009 at 07:37:53PM +0000, Andrew Ross wrote: >>> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote: >>>> Instead of this approach, I think we should simply store those <driver>.rc >>>> files in the drivers subdirectory of the source tree and let CMake install >>>> them or not depending on what drivers are configured. We could then rename >>>> get-drv-info to test-drv-info. Then test-drv-info would only be run for >>>> normal builds (and not for cross builds) and the tests that it would do >>>> would be (1) and (2) checking that the existing <driver>.rc file is correct. >>> >>> I like this approach. Going further down this route, we could >>> also commit the generated header files to svn. The tools to build >>> them could be kept for making updates, as we do with the Hershey >>> fonts for example. This would eliminate build time executables >>> altogether which is probably a good thing. >> >> The only complication of this approach is what happens for drivers >> which support multiple devices (e.g. cairo) which can be independently >> turned on or off. The .rc file will change depending on options. The >> simple "commit the file" approach won't be adequate for this. > > Agreed. Taking it one step further, have <driver>.rc.full files in the > source tree which have the full complement of devices for a given device > driver, and let CMake parse that file (using regular expressions, not direct > CMake configuration variables as in *.in files) to generate the correct > <driver>.rc file in the build tree that drops the unwanted devices. I have now implemented this (revision 9713) using <driver>.rc.in as the names of the template files which are parsed by cmake/modules/drivers-finish.cmake to generate the needed <driver>.rc files. I have tested this cmake logic for the cases where all devices are enabled, where a subset of the devices are enabled, and where none of the devices are enabled for a given device driver, and the results seem fine. I have turned off everything having to do with get-drv-info using the TEST_DYNDRIVERS option (which currently defaults to OFF). If a device does not work for you for a platform that is inaccessible to me (these will mostly be the OS X- and Windows-specific drivers), please use -DTEST_DYNDRIVERS=ON and copy the resulting *.rc file back to drivers/*.rc.in, and commit that file so that -DTEST_DYNDRIVERS=OFF works from then on for you and others. To finish up this effort, I plan to rename get-drv-info as test-drv-info and make a series of tests comparing its output with the *.rc files that are configured by CMake. Andrew, I leave it to you to follow up by simplifying the cross-build logic now that the *.rc files are configured rather than generated by an executable that must be built and run. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-03-11 18:24:39
|
On 2009-03-10 20:07-0700 Alan W. Irwin wrote: > To finish up this effort, I plan to rename get-drv-info as test-drv-info and > make a series of tests comparing its output with the *.rc files that are > configured by CMake. DONE (revision 9725). The TEST_DYNDRIVERS option is ON by default and is always run. It sets up a custom target test_dyndrivers which compares the *.rc output of test-drv-info with the *.rc file created by the CMake configuration logic to be sure the dynamic device has been built correctly. So from now on if there is any *.rc.in file missing from drivers, you should get a test failure. Subsequently (assuming you have enabled all devices for that particular device driver) all you have to do is copy the *.rc file from drivers/test_dyndrivers_dir back to drivers/*.rc.in, and commit the result. Then touch cmake/modules/drivers-finish.cmake (or probably any other CMake file) to convince cmake to re-run to generate the correct *.rc file. All should be well from then on. I have just exercised this method with the Tk-related *.rc.in files which were missing, and it works as described. > > Andrew, I leave it to you to follow up by simplifying the cross-build logic > now that the *.rc files are configured rather than generated by an executable > that must be built and run. I have done this as well since it turned out to be so easy. I stripped all the old cross-build logic out and created the above target only for the case of TEST_DYNDRIVERS AND NOT CMAKE_CROSSCOMPILING. (I did a similar thing for test_nistcd as well and also changed to always running that test.) Unless anybody else has problems with the *.rc files that cannot be corrected as indicated above, I think this mini-project has been completed. (And similarly with the libnistcd mini-project.) 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-03-04 17:18:45
|
On 2009-03-04 10:58-0000 Andrew Ross wrote: > Thinking about it, get-drv-info is only extracting symbols for the installed > drivers which are in the source code anyway. There is no reason we couldn't > have some alternative way of doing this using cmake or some scripting which > would not rely on compiling an executable. This would be more portable for > cross-compiling. > > I think the reason it might have worked in my case (I haven't checked) is > that both platforms were using elf format object code. No guarantees in > general though. Overnight, I have had similar thoughts. I agree with your previous post the ssh approach would not be a good general approach so let's forget it. Also, we should note that the current get-drv-info has two tasks that it does; (1) it checks that dynamic loading works for the plug-in, and (2) it generates the <driver>.rc file. Instead of this approach, I think we should simply store those <driver>.rc files in the drivers subdirectory of the source tree and let CMake install them or not depending on what drivers are configured. We could then rename get-drv-info to test-drv-info. Then test-drv-info would only be run for normal builds (and not for cross builds) and the tests that it would do would be (1) and (2) checking that the existing <driver>.rc file is correct. We could also get CMake/grep/etc. to generate the <driver>.rc files using the ":[0-9]*:" regex in driver source files, but IMO that would be overkill and potentially fragile against future drivers using that pattern for other purposes. Thus, I favour committing the existing generated <driver>.rc files into our subversion repository, and hand-editing of <driver>.rc for new device drivers. Any problems with that low-tech approach would quickly be discovered by test-drv-info for normal builds. 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 __________________________ |
From: Thomas S. <th...@ws...> - 2009-03-04 19:08:32
|
>> >> -Anyway, example1 runs on my windows machine with this errorish >> condition: >> *** PLPLOT ERROR, ABORTING OPERATION *** >> plInitDispatchTable: Could not open drivers directory, aborting >> operation >> PLplot library version: 5.9.2 >> got here -- 0 > > You are using the dynamic drivers and it is unable to open the > directory where the driver information is. Look at the function > plGetDrvDir(). As long as you are not in the build tree (determined by > plInBuildTree()) you should be able to set the environment variable > PLPLOT_DRV_DIR to let PLplot find the *.rc files (for every dynamic > driver there is a .rc file). > > > HTH, > Werner ======= session from "workstation" 2008 (http://www.win2008workstation.com/wordpress/) C:\Users\thomas\Desktop\cmake-plplot>set PLPLOT_DRV_DIR=./ C:\Users\thomas\Desktop\cmake-plplot>x01c.exe PLplot library version: 5.9.2 got here -- 0 Plotting Options: Enter device number or keyword: [ctrl-c] C:\Users\thomas\Desktop\cmake-plplot>dir Volume in drive C has no label. Volume Serial Number is FACF-4976 Directory of C:\Users\thomas\Desktop\cmake-plplot 03/04/2009 01:05 PM <DIR> . 03/04/2009 01:05 PM <DIR> .. 03/03/2009 04:07 PM 136,699 cairo.dll 03/03/2009 04:07 PM 0 cairo.rc 01/06/2009 02:32 PM 781,961 libcairo-2.dll 03/03/2009 03:24 PM 50,384 libcsirocsa.dll 01/06/2009 02:32 PM 295,457 libgobject-2.0-0.dll 01/06/2009 02:32 PM 321,611 libpango-1.0-0.dll 01/06/2009 02:32 PM 78,785 libpangocairo-1.0-0.dll 03/03/2009 03:24 PM 432,714 libplplotd.dll 01/06/2009 02:32 PM 182,015 libpng12-0.dll 03/03/2009 03:24 PM 44,580 libqsastime.dll 03/03/2009 03:24 PM 146,418 ps.dll 03/03/2009 04:09 PM 0 ps.rc 03/03/2009 04:10 PM 38,346 x01c.exe 01/06/2009 02:32 PM 55,808 zlib1.dll 14 File(s) 2,564,778 bytes 2 Dir(s) 424,359,665,664 bytes free C:\Users\thomas\Desktop\cmake-plplot>set PLPLOT_DRV_DIR=C:\Users\thomas\Desktop\cmake-plplot C:\Users\thomas\Desktop\cmake-plplot>x01c.exe PLplot library version: 5.9.2 got here -- 0 Plotting Options: Enter device number or keyword: [ctrl-c] C:\Users\thomas\Desktop\cmake-plplot>echo %PLPLOT_DRV_DIR% C:\Users\thomas\Desktop\cmake-plplot ============== How about setting a hard coded path? How should I try that? |
From: Andrew R. <and...@us...> - 2009-03-04 19:30:12
|
On Wed, Mar 04, 2009 at 01:12:03PM -0600, Thomas Stover wrote: > > >> > >> -Anyway, example1 runs on my windows machine with this errorish > >> condition: > >> *** PLPLOT ERROR, ABORTING OPERATION *** > >> plInitDispatchTable: Could not open drivers directory, aborting > >> operation > >> PLplot library version: 5.9.2 > >> got here -- 0 > > > > You are using the dynamic drivers and it is unable to open the > > directory where the driver information is. Look at the function > > plGetDrvDir(). As long as you are not in the build tree (determined by > > plInBuildTree()) you should be able to set the environment variable > > PLPLOT_DRV_DIR to let PLplot find the *.rc files (for every dynamic > > driver there is a .rc file). > > > > > > HTH, > > Werner > ======= session from "workstation" 2008 > (http://www.win2008workstation.com/wordpress/) > > C:\Users\thomas\Desktop\cmake-plplot>set PLPLOT_DRV_DIR=./ > > C:\Users\thomas\Desktop\cmake-plplot>x01c.exe > PLplot library version: 5.9.2 > got here -- 0 > > Plotting Options: > > Enter device number or keyword: [ctrl-c] > > C:\Users\thomas\Desktop\cmake-plplot>dir > Volume in drive C has no label. > Volume Serial Number is FACF-4976 > > Directory of C:\Users\thomas\Desktop\cmake-plplot > > 03/04/2009 01:05 PM <DIR> . > 03/04/2009 01:05 PM <DIR> .. > 03/03/2009 04:07 PM 136,699 cairo.dll > 03/03/2009 04:07 PM 0 cairo.rc > 01/06/2009 02:32 PM 781,961 libcairo-2.dll > 03/03/2009 03:24 PM 50,384 libcsirocsa.dll > 01/06/2009 02:32 PM 295,457 libgobject-2.0-0.dll > 01/06/2009 02:32 PM 321,611 libpango-1.0-0.dll > 01/06/2009 02:32 PM 78,785 libpangocairo-1.0-0.dll > 03/03/2009 03:24 PM 432,714 libplplotd.dll > 01/06/2009 02:32 PM 182,015 libpng12-0.dll > 03/03/2009 03:24 PM 44,580 libqsastime.dll > 03/03/2009 03:24 PM 146,418 ps.dll > 03/03/2009 04:09 PM 0 ps.rc > 03/03/2009 04:10 PM 38,346 x01c.exe > 01/06/2009 02:32 PM 55,808 zlib1.dll > 14 File(s) 2,564,778 bytes > 2 Dir(s) 424,359,665,664 bytes free > > C:\Users\thomas\Desktop\cmake-plplot>set > PLPLOT_DRV_DIR=C:\Users\thomas\Desktop\cmake-plplot > > C:\Users\thomas\Desktop\cmake-plplot>x01c.exe > PLplot library version: 5.9.2 > got here -- 0 > > Plotting Options: > > Enter device number or keyword: [ctrl-c] > > C:\Users\thomas\Desktop\cmake-plplot>echo %PLPLOT_DRV_DIR% > C:\Users\thomas\Desktop\cmake-plplot > > ============== > > How about setting a hard coded path? How should I try that? Agh! I think the problem might be that the .rc files are blank. Just as a test could you try addding the following to cairo.rc (include only the lines referring to the drivers you have) xcairo:Cairo X Windows Driver:1:cairo:59:xcairo pdfcairo:Cairo PDF Driver:0:cairo:60:pdfcairo pscairo:Cairo PS Driver:0:cairo:61:pscairo svgcairo:Cairo SVG Driver:0:cairo:62:svgcairo pngcairo:Cairo PNG Driver:0:cairo:63:pngcairo Also might be useful to add the following to ps.rc (this driver will work without any external libraries so is a good test). ps:PostScript File (monochrome):0:ps:29:psm psc:PostScript File (color):0:ps:30:psc Then repeat your above tests. Any difference? Andrew |
From: Thomas S. <th...@ws...> - 2009-03-04 21:19:32
|
OK after many, many steps, I built x01c.c for x86_64 windows from an ubuntu x86_64 box. pngcairo works fine. Mono and color ps crashes though. Also I never was able to disable pkg-config, which may or may not be why during the build process I had to obtain the import libs for things like freetype, font config, and various pango versions. It doesn't look like my end result needs these files though. Just to be sure I copied them over and that didn't effect the postscript driver crashing. For me though the extcairo was all I needed, so this will work. If anyone wants more tests, details or whatever just let me know. Also thanks again to everyone who helped me out with all this. This has been one of the most helpful mailing lists I've seen. |
From: Thomas S. <th...@ws...> - 2009-03-04 19:57:56
|
Andrew Ross wrote: > Agh! I think the problem might be that the .rc files are blank. > Just as a test could you try addding the following to cairo.rc > (include only the lines referring to the drivers you have) > > xcairo:Cairo X Windows Driver:1:cairo:59:xcairo > pdfcairo:Cairo PDF Driver:0:cairo:60:pdfcairo > pscairo:Cairo PS Driver:0:cairo:61:pscairo > svgcairo:Cairo SVG Driver:0:cairo:62:svgcairo > pngcairo:Cairo PNG Driver:0:cairo:63:pngcairo > > Also might be useful to add the following to ps.rc (this driver > will work without any external libraries so is a good test). > > ps:PostScript File (monochrome):0:ps:29:psm > psc:PostScript File (color):0:ps:30:psc > > Then repeat your above tests. > > Any difference? > > Andrew > After adding the .fnt file over to that directory as well. The ps and color ps work fine. (I did actually look at the output to make sure.) The cairo stuff fails gracefully like this: Plotting Options: < 1> ps PostScript File (monochrome) < 2> psc PostScript File (color) < 3> pngcairo Cairo PNG Driver < 4> extcairo Cairo External Context Driver Enter device number or keyword: 3 Unable to load driver: cairo. *** PLPLOT ERROR, IMMEDIATE EXIT *** Unable to load driver Program aborted I'll try rebuild to make sure. Is there any debug flags or anything you want me to try and get some more verbose info with? |
From: Thomas S. <th...@ws...> - 2009-03-04 20:06:07
|
Thomas Stover wrote: > Andrew Ross wrote: >> Agh! I think the problem might be that the .rc files are blank. >> Just as a test could you try addding the following to cairo.rc >> (include only the lines referring to the drivers you have) >> >> xcairo:Cairo X Windows Driver:1:cairo:59:xcairo >> pdfcairo:Cairo PDF Driver:0:cairo:60:pdfcairo >> pscairo:Cairo PS Driver:0:cairo:61:pscairo >> svgcairo:Cairo SVG Driver:0:cairo:62:svgcairo >> pngcairo:Cairo PNG Driver:0:cairo:63:pngcairo >> >> Also might be useful to add the following to ps.rc (this driver >> will work without any external libraries so is a good test). >> >> ps:PostScript File (monochrome):0:ps:29:psm >> psc:PostScript File (color):0:ps:30:psc >> >> Then repeat your above tests. >> >> Any difference? >> >> Andrew >> > > After adding the .fnt file over to that directory as well. The ps and > color ps work fine. (I did actually look at the output to make sure.) > The cairo stuff fails gracefully like this: > Plotting Options: > < 1> ps PostScript File (monochrome) > < 2> psc PostScript File (color) > < 3> pngcairo Cairo PNG Driver > < 4> extcairo Cairo External Context Driver > > Enter device number or keyword: 3 > Unable to load driver: cairo. > > *** PLPLOT ERROR, IMMEDIATE EXIT *** > Unable to load driver > Program aborted > > I'll try rebuild to make sure. Is there any debug flags or anything > you want me to try and get some more verbose info with? > Correction: the cairo stuff works fine! I busted out the trusty dependency walker program and realized I had a few missing dlls. I would have noticed this before, but I have this thing about wanting to know what files are need to do what. Next up win64 tests... |
From: Thomas S. <th...@ws...> - 2009-03-02 20:02:24
|
Alan W. Irwin wrote: > I think doing your own specific Makefile based build system for PLplot > would > work, but I also think it would take a rather large effort on your > part with > no beneficial networking effects at all (nobody else would use your > approach > so you could gain little help from anybody else or lend help to anybody > else). Yes definitely undesirable. However this might the fastest way to confirm that the end goal is even possible. Then I can go back to possibly patching the mainline build system. > Furthermore, developing your CMake skills is worth doing in its own > right since an increasing number of projects (KDE is probably the > biggest of > these) use it. Therefore, I encourage you to stick with CMake a bit > longer > even though you are unfamiliar with it at the moment. Noted. I'm currently on neck deep into the world of scons, and I do have a multitasking threshold before my head explodes. :) > ... > Specifically, build just the plplot C library (with libqhull and freetype > dropped to eliminate those dependencies and with no dynamic drivers to > eliminate the dependence on dynamic loading libraries) What features go away by dropping qhull? -- www.thomasstover.com |
From: Alan W. I. <ir...@be...> - 2009-03-02 21:55:17
|
On 2009-03-02 14:05-0600 Thomas Stover wrote: > Alan W. Irwin wrote: >> Specifically, build just the plplot C library (with libqhull and freetype >> dropped to eliminate those dependencies and with no dynamic drivers to >> eliminate the dependence on dynamic loading libraries) > > What features go away by dropping qhull? You have to use lower-quality fallbacks for interpolating between a "random" bunch of points and a rectangular grid of points using plgriddata, see src/plgridd.c. The only standard example affected by this is example 21 since it is the only one that uses the plgriddata command. However, even then the fallbacks are acceptable. For the record, dropping the direct dependency on freetype is potentially more serious since that means you are stuck with the Hershey font fallback for many device drivers. Those fonts give OK-looking results on printers, but those fonts are unhinted and therefore they give bad-looking results on displays. This issue does not affect cairo devices directly since they do not rely on the plplot core library for font handling. Instead, they rely on the cairo stack of libraries to handle fonts. That stack does include freetype (and a whole lot more) so in practical terms once you have the cairo device driver working for a cross build, then you should be able to add the cross-build freetype dependence to the plplot core library without any issues. 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 __________________________ |