PLplot

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
__________________________

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
> __________________________


-- 
 http://www.thomasstover.com

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/cmake@...>). 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: smekal@...
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

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/cmake@...>). 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
__________________________

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.

Correction, it works. I just had to properly set the hard coded data 
directory. Actual cross compile test comming soon...

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
__________________________

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: smekal@...
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

I have no idea why this works, but it seems to! All I changed is the 
data dir. This is astonishing. Surely there must be some problems that 
show up later. I think I'm missing support for some major stuff - were 
does this nearest neighbors library come into the picture? Never the 
less, here is an example of a cross compiling a win32 C core library 
only with extcairo support. I'll try some more stuff and report back. 
Also to anyone every trying this the windows program dependency walker 
is invaluable in trying to figure out all the files you need to copy over.

file required to run the example, "test1.exe":

created by the makefile:
csirocsa.dll
plplot.dll
test1.exe

others:
libcairo-2.dll
libglib-2.0-0.dll
libgmodule-2.0-0.dll
libgobject-2.0-0.dll
libpango-1.0-0.dll
libpangocairo-1.0-0.dll
libpangowin32-1.0-0.dll
libpng12-0.dll
zlib1.dll

plstnd5.fnt
plxtnd5.fnt                 

========= Makefile.win32 ================
#set CC to your compiler
#do mkdir objwin32; mkdir win32
#set pkg-config path ie: 
PKG_CONFIG_PATH=/opt/crosscompilers/win32/mingw/lib/pkgconfig make -f 
Makefile.win32

CC = /opt/crosscompilers/win32/bin/i686-mingw32-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 = ./objwin32/cairo.o ./objwin32/null.o ./objwin32/plargs.o \
          ./objwin32/plbox.o ./objwin32/plbuf.o ./objwin32/plcont.o \
          ./objwin32/plcore.o ./objwin32/plctrl.o ./objwin32/plcvt.o \
          ./objwin32/pldtik.o ./objwin32/plfill.o ./objwin32/plgridd.o \
          ./objwin32/plhist.o ./objwin32/plimage.o ./objwin32/plline.o \
          ./objwin32/plmap.o ./objwin32/plot3d.o ./objwin32/plpage.o \
          ./objwin32/plsdef.o ./objwin32/plshade.o ./objwin32/plstdio.o \
          ./objwin32/plstripc.o ./objwin32/plsym.o ./objwin32/pltick.o \
          ./objwin32/plvect.o ./objwin32/plvpor.o ./objwin32/plwind.o \
          ./objwin32/pdfutils.o ./objwin32/mt19937ar.o

all: ./win32/plplot.dll ./win32/csirocsa.dll ./win32/test1.exe

./objwin32/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 ./objwin32/csa.o

./win32/csirocsa.dll : ./objwin32/csa.o
    $(CC) -shared -o ./win32/csirocsa.dll 
-Wl,--out-implib,./win32/csirocsa.dll.a

./win32/plplot.dll : $(LIBOBJS) ./win32/csirocsa.dll
    $(CC) -shared -o ./win32/plplot.dll $(LIBOBJS) 
-Wl,--out-implib,./win32/plplot.dll.a \
          $(LIBS) ./win32/csirocsa.dll

./objwin32/mt19937ar.o : ./src/mt19937ar.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/mt19937ar.c -o ./objwin32/mt19937ar.o

./objwin32/cairo.o : ./drivers/cairo.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./drivers/cairo.c -o ./objwin32/cairo.o

./objwin32/null.o : ./drivers/null.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./drivers/null.c -o ./objwin32/null.o

./objwin32/plargs.o : ./src/plargs.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plargs.c -o ./objwin32/plargs.o

./objwin32/plbox.o : ./src/plbox.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plbox.c -o ./objwin32/plbox.o

./objwin32/plbuf.o : ./src/plbuf.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plbuf.c -o ./objwin32/plbuf.o

./objwin32/plcont.o : ./src/plcont.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plcont.c -o ./objwin32/plcont.o

./objwin32/plcore.o : ./src/plcore.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plcore.c -o ./objwin32/plcore.o

./objwin32/plctrl.o : ./src/plctrl.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plctrl.c -o ./objwin32/plctrl.o

./objwin32/plcvt.o : ./src/plcvt.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plcvt.c -o ./objwin32/plcvt.o

./objwin32/pldtik.o : ./src/pldtik.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/pldtik.c -o ./objwin32/pldtik.o

./objwin32/plfill.o : ./src/plfill.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plfill.c -o ./objwin32/plfill.o

./objwin32/plgridd.o : ./src/plgridd.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plgridd.c -o ./objwin32/plgridd.o

./objwin32/plhist.o : ./src/plhist.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plhist.c -o ./objwin32/plhist.o

./objwin32/plimage.o : ./src/plimage.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plimage.c -o ./objwin32/plimage.o

./objwin32/plline.o : ./src/plline.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plline.c -o ./objwin32/plline.o

./objwin32/plmap.o : ./src/plmap.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plmap.c -o ./objwin32/plmap.o

./objwin32/plot3d.o : ./src/plot3d.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plot3d.c -o ./objwin32/plot3d.o

./objwin32/plpage.o : ./src/plpage.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plpage.c -o ./objwin32/plpage.o

./objwin32/plsdef.o : ./src/plsdef.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plsdef.c -o ./objwin32/plsdef.o

./objwin32/plshade.o : ./src/plshade.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plshade.c -o ./objwin32/plshade.o

./objwin32/plstdio.o : ./src/plstdio.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plstdio.c -o ./objwin32/plstdio.o

./objwin32/plstripc.o : ./src/plstripc.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plstripc.c -o ./objwin32/plstripc.o

./objwin32/pltick.o : ./src/pltick.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/pltick.c -o ./objwin32/pltick.o

./objwin32/plvect.o : ./src/plvect.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plvect.c -o ./objwin32/plvect.o

./objwin32/plvpor.o : ./src/plvpor.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plvpor.c -o ./objwin32/plvpor.o

./objwin32/plwind.o : ./src/plwind.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plwind.c -o ./objwin32/plwind.o

./objwin32/plsym.o : ./src/plsym.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/plsym.c -o ./objwin32/plsym.o

./objwin32/pdfutils.o : ./src/pdfutils.c $(HEADERS)
    $(CC) $(CFLAGS) -c ./src/pdfutils.c -o ./objwin32/pdfutils.o

./win32/test1.exe : ./win32/plplot.dll
    $(CC) -I ./include `pkg-config --cflags cairo` test1.c 
./win32/plplot.dll.a \
          ./win32/csirocsa.dll.a `pkg-config --libs cairo` -o 
./win32/test1.exe

clean:
    rm -f ./objwin32/*
    rm -f ./win32/*



Thomas Stover wrote:
> Correction, it works. I just had to properly set the hard coded data 
> directory. Actual cross compile test comming soon...
>

Hi Alan and Thomas,
>
> 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.
This should work "out of the box" since on Windows there is no library 
provided at all by MinGW or Visual C++. I wrote replacement functions 
for the used libltdl (?) functions which are compiled and linked in if 
cmake has WIN32 set. So this should be no problem, but if dynamic 
drivers are enabled, get-drv-info.exe is run for every device during the 
compilation to create some files - this would already need Wine I think. 
I'm not sure if this "just works".

Regards,
Werner

-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: smekal@...
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

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?

-- 
 http://www.thomasstover.com

Is there an "official" precompiled release for win32 and/or win64? If 
that were the case I would just use that, and bring it into my cross 
environment. On the other hand, if the standard installation is  for one 
is to build their own for maximum tool chain & platform compatibility, 
then cross compilation is more of valid concept. In my case plplot 
itself is one of many dependences. As with builds for embedded targets 
for instance, when creating home built dependencies is required or 
desired, configuring them for the minimal feature set needed is common. 
So from that perspective, a custom stripped down build of plplot without 
dynamic drivers that would likely only be deployed as a dependency of 
another project is not really a problem. Especially if that allows for 
larger goals to be achieved - in my case a linux hosted, multi targeted 
continuous integration environment.

The cmake build system of course is still used for a native linux build. 
However I also target things like embedded arm linux environments with 
cross compilers, and so I might handle them the same way (I have to deal 
with things like problems from mixing object code from different gcc 
versions). With luck I'll get cmake cross builds working as well.  In 
the mean time if someone wants, I can make a wiki page or something 
explaining how to do it this way.

Hopefully I can at least get a "feature complete" version in action, 
even if it lacks all the drivers and bindings.

Again I'm so thankful for plplot existing, and I look forward to 
contributing in some way.

Werner Smekal wrote:
> Hi Alan and Thomas,
>>
>> 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.
> This should work "out of the box" since on Windows there is no library 
> provided at all by MinGW or Visual C++. I wrote replacement functions 
> for the used libltdl (?) functions which are compiled and linked in if 
> cmake has WIN32 set. So this should be no problem, but if dynamic 
> drivers are enabled, get-drv-info.exe is run for every device during 
> the compilation to create some files - this would already need Wine I 
> think. I'm not sure if this "just works".
>
> Regards,
> Werner
>

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
__________________________

On 2009-03-02 14:57-0600 Thomas Stover wrote:

> Is there an "official" precompiled release for win32 and/or win64?

That has been discussed since it is fairly straightforward to do that
with CMake, but it hasn't actually happened yet.

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
__________________________

Hi,

On 02.03.2009, at 22:57, Alan W. Irwin wrote:

> On 2009-03-02 14:57-0600 Thomas Stover wrote:
>
>> Is there an "official" precompiled release for win32 and/or win64?
>
> That has been discussed since it is fairly straightforward to do that
> with CMake, but it hasn't actually happened yet.

I'm actually working on that and have already written a script to  
automatically obtain and build some dependencies and then the PLplot  
library, but didn't manage to test and upload the binaries somewhere,  
but it is on my ToDo list.

Regards,
Werner

>
> 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
> __________________________
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San  
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the  
> Enterprise
> -Strategies to boost innovation and cut costs with open source  
> participation
> -Receive a $600 discount off the registration fee with the source  
> code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
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

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

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.

On 2009-03-03 12:49-0000 Andrew Ross wrote:

> On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
>> [...]In sum, my advice [to Thomas was] 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.

Andrew, I really appreciate you working out the initial cross-build issues.
That proof of concept for the simple case encourages me to think that CMake
is up to the full cross-build job for all aspects of PLplot where the
appropriate non-native libraries are available.

I have thought of some issues for the get-drv-info case. How does
a Linux-built get-drv-info executable work at all for a shared object
(cross-)built for Windows with MinGW?  (Apparently it worked for you, but I
don't understand why.) Also, looking forward to the more complicated case
where the driver has dependencies, how does a native built get-drv-info
using the native libraries libltdl and libdl check the linking of the
non-native device driver plug-ins against non-native libraries?  Unless
I missed something, that is going to be a showstopper for that method.

In case I am right, one way out of the mess is to build get-drv-info on the
non-native platform and also run it (say via ssh) on the non-native platform
with the non-native libraries.  If you think that is a good alternative,
then we could revert all your build-time executable changes (in particular
restoring the LOCATION method, see further comment below), and run the
cross-built build executables in the non-native environment instead.

However, if it turns out that you really do need build-time executables
built natively, then I understand why you have to refer to the executable by
some alternative means for the cross-build case, but I would like to see the
LOCATION method restored for ordinary non-cross build case.  That is
essential for Windows (where you have an executable suffix to keep track of
and I think there were other issues as well), and the LOCATION method just
makes life easier all around for dealing with dependencies, for example.

>
> 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.

Yes.  This may already be covered in the CMake cross-build wiki, but instead
of setting PKG_CONFIG_PATH (which always sets the native pkg-config default
path in addition to the non-native one you set), you should set
PKG_CONFIG_LIBDIR (which sets only the non-native path that you specify and
which excludes the native pkg-config path).

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
__________________________

>>
>> 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.
>
> Yes.  This may already be covered in the CMake cross-build wiki, but 
> instead
> of setting PKG_CONFIG_PATH (which always sets the native pkg-config 
> default
> path in addition to the non-native one you set), you should set
> PKG_CONFIG_LIBDIR (which sets only the non-native path that you 
> specify and
> which excludes the native pkg-config path).

I have read that  in places to, and have yet fully understand the 
distinction between the two. We use PKG_CONFIG_PATH for cross builds all 
the time and get results. For one thing, how would pkg-config 'know' 
what is native and non-native? I wouldn't want a cross build to ever 
link to a native lib anyway. In a build system that needed both/many 
separate pkg-config environments would need to be specified as such 
anyway. In the case of plplot this is done with the separate steps for 
the native and cross build. In some things I've put together, more than 
one can be explicitly specified for different purposes in one step.

Thomas Stover wrote:
> 
> -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.
> 

That was a problem with the cairo.cmake file, extcairo should build by 
itself now (as of v9671). Thanks for pointing out the problem.

best,
-Hazen

On 2009-03-03 17:59-0600 Thomas Stover wrote:

>
>>> 
>>> 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.
>> 
>> Yes.  This may already be covered in the CMake cross-build wiki, but 
>> instead
>> of setting PKG_CONFIG_PATH (which always sets the native pkg-config default
>> path in addition to the non-native one you set), you should set
>> PKG_CONFIG_LIBDIR (which sets only the non-native path that you specify and
>> which excludes the native pkg-config path).
>
> I have read that  in places to, and have yet fully understand the distinction 
> between the two. We use PKG_CONFIG_PATH for cross builds all the time and get 
> results. For one thing, how would pkg-config 'know' what is native and 
> non-native?

pkg-config knows exactly what PATHS to check by what you specify to
PKG_CONFIG_LIBDIR.  If a non-native package does not exist, the
PKG_CONFIG_LIBDIR method will do that right thing which is to report it does
not exist while for this case the PKG_CONFIG_PATH method will fall back to
the native path (check the man page for pkg-config) which obviously is the
wrong thing to do for cross-builds. This is why the PKG_CONFIG_PATH method 
is deprecated for cross-build environments.

> I wouldn't want a cross build to ever link to a native lib 
> anyway.

Exactly, which is why you should always use PKG_CONFIG_LIBDIR for cross
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
__________________________

Hi Thomas,
>

> -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.

Using CMake you're supposed to configure and compile the project in a  
separate build directory, e.g.

mkdir build
cd build
cmake path_to_plplot

Usually there should be no problems recompiling in the same tree, even  
after you changed cmake files (it will reconfigure automatically).  
Still, if you have the feeling something is wrong, just remove the  
build directory and start new. No need to checkout. Don't configure  
and compile in the source tree, this will lead to problems for sure.
>
> -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

Hmm,  plMergeOpts and plparseopts are on line 117/118 for my x01c.c  
(latest svn). Which x01c.c are you using? The types are

const char *array[]   <-> const char **array

array[][] is not the same as **array, but actually the above should be  
okay (and all compilers so far had no problem). Which gcc version is  
that?
>
> -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

>
> 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.

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
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

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.

On Tue, Mar 03, 2009 at 03:44:45PM -0800, Alan Irwin wrote:
> On 2009-03-03 12:49-0000 Andrew Ross wrote:
>
>> On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
>>> [...]In sum, my advice [to Thomas was] 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.
>
> Andrew, I really appreciate you working out the initial cross-build issues.
> That proof of concept for the simple case encourages me to think that CMake
> is up to the full cross-build job for all aspects of PLplot where the
> appropriate non-native libraries are available.
>
> I have thought of some issues for the get-drv-info case. How does
> a Linux-built get-drv-info executable work at all for a shared object
> (cross-)built for Windows with MinGW?  (Apparently it worked for you, but I
> don't understand why.) Also, looking forward to the more complicated case
> where the driver has dependencies, how does a native built get-drv-info
> using the native libraries libltdl and libdl check the linking of the
> non-native device driver plug-ins against non-native libraries?  Unless
> I missed something, that is going to be a showstopper for that method.

I agree this needs more work. Generating the qsastime header and the 
hershey font tables should be fine using the native version of the
executable. get-drv-info is more tricky.

> In case I am right, one way out of the mess is to build get-drv-info on the
> non-native platform and also run it (say via ssh) on the non-native platform
> with the non-native libraries.  If you think that is a good alternative,
> then we could revert all your build-time executable changes (in particular
> restoring the LOCATION method, see further comment below), and run the
> cross-built build executables in the non-native environment instead.

In principle I'm edgy about the ssh route. This would not be available for 
windows which is likely to be one major cross-compilation requirement. An
alternative for windows cross-compiles might be wine. This is looking 
potentially messy though.

The reason I made the LOCATION method changes is that this was the 
recommendation on the cmake wiki. It implied that under cmake 2.6 the
command name in add_custom_command was interpreted as a target name and
so all the dependencies and platform-specific suffixes were handled
automatically so LOCATION was not needed. Of course this needs checking.

>
> However, if it turns out that you really do need build-time executables
> built natively, then I understand why you have to refer to the executable by
> some alternative means for the cross-build case, but I would like to see the
> LOCATION method restored for ordinary non-cross build case.  That is
> essential for Windows (where you have an executable suffix to keep track of
> and I think there were other issues as well), and the LOCATION method just
> makes life easier all around for dealing with dependencies, for example.

If it proves a problem we can probably work around it, but I was unclear how 
to get the LOCATION method to work in a cross-compiling environment. It 
certainly didn't work by default - I tried.

>>
>> 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.
>
> Yes.  This may already be covered in the CMake cross-build wiki, but instead
> of setting PKG_CONFIG_PATH (which always sets the native pkg-config default
> path in addition to the non-native one you set), you should set
> PKG_CONFIG_LIBDIR (which sets only the non-native path that you specify and
> which excludes the native pkg-config path).

I assumed something like this was the case, but not having any other libraries 
to test it with I went with the brute force approach of disabling it. Perhaps
someone could update the wiki with instructions for this?

Andrew

On Tue, Mar 03, 2009 at 03:44:45PM -0800, Alan Irwin wrote:
> On 2009-03-03 12:49-0000 Andrew Ross wrote:
> 
> > On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
> >> [...]In sum, my advice [to Thomas was] 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.
> 
> Andrew, I really appreciate you working out the initial cross-build issues.
> That proof of concept for the simple case encourages me to think that CMake
> is up to the full cross-build job for all aspects of PLplot where the
> appropriate non-native libraries are available.
> 
> I have thought of some issues for the get-drv-info case. How does
> a Linux-built get-drv-info executable work at all for a shared object
> (cross-)built for Windows with MinGW?  (Apparently it worked for you, but I
> don't understand why.) Also, looking forward to the more complicated case
> where the driver has dependencies, how does a native built get-drv-info
> using the native libraries libltdl and libdl check the linking of the
> non-native device driver plug-ins against non-native libraries?  Unless
> I missed something, that is going to be a showstopper for that method.
> 
> In case I am right, one way out of the mess is to build get-drv-info on the
> non-native platform and also run it (say via ssh) on the non-native platform
> with the non-native libraries.  If you think that is a good alternative,
> then we could revert all your build-time executable changes (in particular
> restoring the LOCATION method, see further comment below), and run the
> cross-built build executables in the non-native environment instead.
> 
> However, if it turns out that you really do need build-time executables
> built natively, then I understand why you have to refer to the executable by
> some alternative means for the cross-build case, but I would like to see the
> LOCATION method restored for ordinary non-cross build case.  That is
> essential for Windows (where you have an executable suffix to keep track of
> and I think there were other issues as well), and the LOCATION method just
> makes life easier all around for dealing with dependencies, for example.

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.

Andrew

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
__________________________

>>
>> -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?

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

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

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
__________________________

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?

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...

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.

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

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
__________________________

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
__________________________

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
__________________________