From: Alan W. I. <ir...@be...> - 2010-05-11 16:21:12
|
C++ and OCaml are perfect, and here is the status of the remaining non-perfect bindings: f77 Missing examples : Differing postscript output : 19 Missing stdout : Differing stdout : f95 Missing examples : Differing postscript output : 19 Missing stdout : Differing stdout : java Missing examples : Differing postscript output : 19 Missing stdout : Differing stdout : octave Missing examples : 19 Differing postscript output : Missing stdout : Differing stdout : python Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : tcl Missing examples : Differing postscript output : 19 21 28 Missing stdout : Differing stdout : 21 perl Missing examples : Differing postscript output : 03 06 07 16 19 25 28 29 30 Missing stdout : Differing stdout : 14 ada Missing examples : Differing postscript output : 06 07 19 28 29 Missing stdout : Differing stdout : adathick Missing examples : Differing postscript output : 06 07 19 28 29 Missing stdout : Differing stdout : lua Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : d Missing examples : Differing postscript output : 06 07 19 Missing stdout : Differing stdout : Thanks for everybody's efforts in making C++ and OCaml perfect as well as in propagating the examples 6 and 7 extensions to most of the languages. So we are in considerably better shape than when I reported this status before. Nevertheless, I believe our goal should be to remove at least the remaining examples 06, 07, and 19 differences before the forthcoming release. Examples 06 and 07 only require some straightforward changes to those examples but no API additions. My understanding is that example 19 for octave is a difficult issue so we may have to accept that missing example for this release. But for the remaining languages where example 19 is already implemented, all that needs to be done is to add a wrapper for plstransform (Hez's general transformation API) to the language's API, then add an extra page to example 19 that uses plstransform consistently with what is done for the C example. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-11 17:21:09
|
Alan W. Irwin writes: > C++ and OCaml are perfect, and here is the status of the remaining > non-perfect bindings: > > tcl > Missing examples : > Differing postscript output : 19 21 28 > Missing stdout : > Differing stdout : 21 I believe I've fixed Tcl #19. Let me know if anyone finds otherwise. |
From: Geoffrey F. <geo...@at...> - 2010-05-11 17:29:52
|
Geoffrey Furnish writes: > Alan W. Irwin writes: > > C++ and OCaml are perfect, and here is the status of the remaining > > non-perfect bindings: > > > > tcl > > Missing examples : > > Differing postscript output : 19 21 28 > > Missing stdout : > > Differing stdout : 21 > > I believe I've fixed Tcl #19. Let me know if anyone finds otherwise. BTW, the only difference I see in example 21 postscript output, is the time stamp: [furnish@ziffy]~/devel/pldev/test/examples% diff x21c.psc x21t.psc 6c6 < %%CreationDate: Sat May 8 23:48:27 2010 --- > %%CreationDate: Sat May 8 23:46:23 2010 [furnish@ziffy]~/devel/pldev/test/examples% When I investigated x19, there were huge differences oweing to coordinate transformation problems. However, I assumed the timestamp differnece was just being ignored. But with x21, all I see is the timestamp difference. Is the test output differ taking this into account? Frankly, I don't like the idea of a timestamp in an output file, for exactly this reason. It makes for differences in files that would otherwise be identical. Could we just take the timestamp line out of all the psc output? Why is it there, anyway? Is it a postscript specification? -Geoff |
From: Alan W. I. <ir...@be...> - 2010-05-11 21:27:25
|
On 2010-05-11 12:29-0500 Geoffrey Furnish wrote: > Geoffrey Furnish writes: > > Alan W. Irwin writes: > > > C++ and OCaml are perfect, and here is the status of the remaining > > > non-perfect bindings: > > > > > > tcl > > > Missing examples : > > > Differing postscript output : 19 21 28 > > > Missing stdout : > > > Differing stdout : 21 > > > > I believe I've fixed Tcl #19. Let me know if anyone finds otherwise. > > BTW, the only difference I see in example 21 postscript output, is the time > stamp: Glad you got a good result for that. As I said earlier in this thread my x21 result for Tcl is an artifact of not having Tcl8.5 which also explains the different stdout in my case. That message was This example require Tcl 8.5 or later: use of NaNs > Frankly, I don't like the idea of a timestamp in an output file, for exactly > this reason. It makes for differences in files that would otherwise be > identical. Could we just take the timestamp line out of all the psc output? > Why is it there, anyway? Is it a postscript specification? I believe I have run into PostScript files without a time stamp so I don't think it is necessary. However, the timestamp occurs very early in the file so it is easy to deal with it using tail (or cmp). So I feel neutral about removing the timestamp or not. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-12 17:53:36
|
Alan W. Irwin writes: > On 2010-05-11 12:29-0500 Geoffrey Furnish wrote: > > > Geoffrey Furnish writes: > > > Alan W. Irwin writes: > > > > C++ and OCaml are perfect, and here is the status of the remaining > > > > non-perfect bindings: > > > > > > > > tcl > > > > Missing examples : > > > > Differing postscript output : 19 21 28 > > > > Missing stdout : > > > > Differing stdout : 21 > > > > > > I believe I've fixed Tcl #19. Let me know if anyone finds otherwise. > > > > BTW, the only difference I see in example 21 postscript output, is the > > time stamp: > > As I said earlier in this thread my x21 result for Tcl is an artifact of > not having Tcl8.5 which also explains the different stdout in my case. > That message was > > This example require Tcl 8.5 or later: use of NaNs I've taken a look into Tcl example 21, and I'm not very convinced. What I find is that when I comment out the return which currently bails if you don't have Tcl 8.5, well, everything works fine, as far as I can tell. In particular, the isnan proc appears to me to have been coded in a way that anticipates the non-recognition of the NAN construct by Tcl. However, peering into "svn blame" and "svn log", it seems to me that the lines in questsion were authored by Arjen, in August 2008. So I think it's really up to Arjen to render the final verdict on this. My only input is that I tried running the example on Tcl 8.4, and don't see a problem. It would seem to me we could drop the requirement for 8.5. -Geoff |
From: Arjen M. <arj...@de...> - 2010-05-17 07:31:34
|
Hello, On 2010-05-12 19:53, Geoffrey Furnish wrote: > Alan W. Irwin writes: > > > > This example require Tcl 8.5 or later: use of NaNs > > I've taken a look into Tcl example 21, and I'm not very convinced. What I > find is that when I comment out the return which currently bails if you don't > have Tcl 8.5, well, everything works fine, as far as I can tell. > > In particular, the isnan proc appears to me to have been coded in a way that > anticipates the non-recognition of the NAN construct by Tcl. > > However, peering into "svn blame" and "svn log", it seems to me that the > lines in questsion were authored by Arjen, in August 2008. So I think it's > really up to Arjen to render the final verdict on this. > > My only input is that I tried running the example on Tcl 8.4, and don't see a > problem. It would seem to me we could drop the requirement for 8.5. > I will have a look at this. The procedure isnan was designed to deal with NaNs in all not-too-old versions of Tcl and with all the nastiness that string representations of NaNs present, so I'd say it is okay to drop the Tcl 8.5 requirement. But let me check it too. Regards, Arjen |
From: Maurice L. <mj...@br...> - 2010-05-12 00:37:54
|
On Tuesday, May 11, 2010 at 12:29:42 (-0500) Geoffrey Furnish writes: > BTW, the only difference I see in example 21 postscript output, is the time > stamp: > > [furnish@ziffy]~/devel/pldev/test/examples% diff x21c.psc x21t.psc > 6c6 > < %%CreationDate: Sat May 8 23:48:27 2010 > --- > > %%CreationDate: Sat May 8 23:46:23 2010 > [furnish@ziffy]~/devel/pldev/test/examples% > > When I investigated x19, there were huge differences oweing to coordinate > transformation problems. However, I assumed the timestamp differnece was > just being ignored. > > But with x21, all I see is the timestamp difference. Is the test output > differ taking this into account? > > Frankly, I don't like the idea of a timestamp in an output file, for exactly > this reason. It makes for differences in files that would otherwise be > identical. Could we just take the timestamp line out of all the psc output? > Why is it there, anyway? Is it a postscript specification? According to the postscript reference at: http://www.adobe.com/products/postscript/pdfs/PLRM.pdf the CreationDate command ref is as follows. By my reading it probably can be tossed, but I'm no postscript expert. CreationDate string (Optional; LanguageLevel 3) The date and time at which the color rendering dictionary was created or most recently modified. The value of this entry should be coordinated with the calibrationDateTimeTag attribute of any associated ICC profile, and its syntax should conform to the international standard ASN.1, defined in the document ITU X.208 or ISO/IEC 8824. (ICC profiles are a standard means, defined by an organization called the International Color Consortium, for describing the color properties of a device; they can be translated in a straightforward way to or from a PostScript rendering dictionary.) This entry is included for information only; the Post- Script interpreter does not consult it. -- Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2010-05-11 21:11:54
|
On 2010-05-11 11:43-0500 Geoffrey Furnish wrote: > Hi Alan, > > Alan W. Irwin writes: > > C++ and OCaml are perfect, and here is the status of the remaining > > non-perfect bindings: > > [...] > > tcl > > Missing examples : > > Differing postscript output : 19 21 28 > > Missing stdout : > > Differing stdout : 21 > Hi Geoffrey: Since your question is of general interest to developers, I am posting my reply to the list. > I'm working on Tcl #19. I'm close to getting it straightened out, hope to > commit soon. > > Question: In my own comparisons between the C and Tcl examples, generated by > manual invocation of the various examples, I'm seeing that the psc output has > a timestamp in it. Does your script have a way of filtering that out? Can > you tell me how to observe how that part of this comparison works? To see exactly what scripts are being run, use VERBOSE=1, e.g., make VERBOSE=1 test_diff_psc >& make.out Once you have identified that the script is plplot_test/test_diff.sh(.in), then the answer quickly follows that "tail" is used to get rid of the date stamp before diff is used. Andrew, I believe it was your decision to use tail and diff. Did you consider the possibility of using cmp with the -i option instead? I do notice that the combination of tail and diff takes a noticeable length of time because of the huge number of files involved, but for platforms like Linux I suspect cmp would be considerably faster. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-11 21:50:31
|
Alan W. Irwin writes: > Since your question is of general interest to developers, I am posting my > reply to the list. > > > I'm working on Tcl #19. I'm close to getting it straightened out, hope to > > commit soon. > > > > Question: In my own comparisons between the C and Tcl examples, > > generated by manual invocation of the various examples, I'm seeing that > > the psc output has a timestamp in it. Does your script have a way of > > filtering that out? Can you tell me how to observe how that part of > > this comparison works? > > To see exactly what scripts are being run, use VERBOSE=1, e.g., > > make VERBOSE=1 test_diff_psc >& make.out > > Once you have identified that the script is plplot_test/test_diff.sh(.in), > then the answer quickly follows that "tail" is used to get rid of the date > stamp before diff is used. > > Andrew, I believe it was your decision to use tail and diff. Did you > consider the possibility of using cmp with the -i option instead? I do > notice that the combination of tail and diff takes a noticeable length of > time because of the huge number of files involved, but for platforms like > Linux I suspect cmp would be considerably faster. Uhh... I certainly have no recollection of that. My suggestions would be, in order of preference: 1) eliminate the timestamp in the ps(c) output 2) Use grep -v to elide the one line, then diff the rest. I am using Tcl 8.5 at the moment, and did not recall the earlier portion of the thread you quoted. I am still a long way from being caught up, in any meaningful sense of the word. But at least I managed to get something done this release cycle. |
From: Alan W. I. <ir...@be...> - 2010-05-12 03:30:45
|
Hi Geoffrey: Your recent revision (I am using revision 10991) to make a plstransform wrapper to Tcl builds okay, but actual use of plstransform for example 19 does not work for me. I get Unable to evaluate Tcl-side coordinate transform. repeated 13557 times in examples/x19t_psc.txt, the file that captures stdout for the tcl version of example 19. That message is apparently coming from Tcl_transform defined in bindings/tcl/tclAPI.c. I am running the development version of Tcl-8.4 (package tcl8.4-dev version 8.4.19-2) for Debian Lenny. The relevant lines from cmake output are -- TCL_TCLSH = /usr/bin/tclsh -- TCL_INCLUDE_PATH = /usr/include/tcl8.4 -- TCL_LIBRARY = /usr/lib/libtcl8.4.so If you try Tcl-8.4 do you get the same error? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-12 16:22:34
|
Alan W. Irwin writes: > Hi Geoffrey: > > Your recent revision (I am using revision 10991) to make a plstransform > wrapper to Tcl builds okay, but actual use of plstransform for example 19 > does not work for me. I get > > Unable to evaluate Tcl-side coordinate transform. > > repeated 13557 times in examples/x19t_psc.txt, the file that captures stdout > for the tcl version of example 19. That message is apparently coming > from Tcl_transform defined in bindings/tcl/tclAPI.c. > > I am running the development version of Tcl-8.4 (package tcl8.4-dev version > 8.4.19-2) for Debian Lenny. The relevant lines from cmake output > are > > -- TCL_TCLSH = /usr/bin/tclsh > -- TCL_INCLUDE_PATH = /usr/include/tcl8.4 > -- TCL_LIBRARY = /usr/lib/libtcl8.4.so > > If you try Tcl-8.4 do you get the same error? BTW, taking a cue from the wiki, I added some options on the cmake line like this: % cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix -DCMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include -DCMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib .. ... -- Looking for include paths and libraries for Tcl/Tk -- Found Tclsh: /home/furnish/devel/8.4/prefix/bin/tclsh -- Found TCL: /usr/lib64/libtcl.so -- Found TCLTK: /usr/lib64/libtcl.so -- Found TK: /usr/lib64/libtk.so -- Looking for include paths and libraries for Tcl/Tk - found -- Looking for tclsh -- Looking for tclsh - found -- TCL_TCLSH = /home/furnish/devel/8.4/prefix/bin/tclsh -- TCL_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include -- TCL_LIBRARY = /usr/lib64/libtcl.so -- Itcl not available or not compatible with current Tcl shell -- TK_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include;/usr/include -- TK_LIBRARY = /usr/lib64/libtk.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so But, it still picks up Tcl/Tk libs from /usr/lib64, even though the ones we need are right there in the named library dir: % ls $HOME/devel/8.4/prefix/lib libtcl8.4.so libtk8.4.so tcl8.4 tk8.4 libtclstub8.4.a libtkstub8.4.a tclConfig.sh tkConfig.sh -Geoff |
From: Alan W. I. <ir...@be...> - 2010-05-12 19:05:07
|
On 2010-05-12 11:22-0500 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > Hi Geoffrey: > > > > Your recent revision (I am using revision 10991) to make a plstransform > > wrapper to Tcl builds okay, but actual use of plstransform for example 19 > > does not work for me. I get > > > > Unable to evaluate Tcl-side coordinate transform. > > > > repeated 13557 times in examples/x19t_psc.txt, the file that captures stdout > > for the tcl version of example 19. That message is apparently coming > > from Tcl_transform defined in bindings/tcl/tclAPI.c. > > > > I am running the development version of Tcl-8.4 (package tcl8.4-dev version > > 8.4.19-2) for Debian Lenny. The relevant lines from cmake output > > are > > > > -- TCL_TCLSH = /usr/bin/tclsh > > -- TCL_INCLUDE_PATH = /usr/include/tcl8.4 > > -- TCL_LIBRARY = /usr/lib/libtcl8.4.so > > > > If you try Tcl-8.4 do you get the same error? > > BTW, taking a cue from the wiki, I added some options on the cmake line like > this: > > % cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix -DCMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include -DCMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib .. That CMAKE_INCLUDE_PATH is incorrect; you should append /tcl8.4 to it. > ... > -- Looking for include paths and libraries for Tcl/Tk > -- Found Tclsh: /home/furnish/devel/8.4/prefix/bin/tclsh > -- Found TCL: /usr/lib64/libtcl.so > -- Found TCLTK: /usr/lib64/libtcl.so > -- Found TK: /usr/lib64/libtk.so > -- Looking for include paths and libraries for Tcl/Tk - found > -- Looking for tclsh > -- Looking for tclsh - found > -- TCL_TCLSH = /home/furnish/devel/8.4/prefix/bin/tclsh > -- TCL_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include > -- TCL_LIBRARY = /usr/lib64/libtcl.so > -- Itcl not available or not compatible with current Tcl shell > -- TK_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include;/usr/include > -- TK_LIBRARY = /usr/lib64/libtk.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so > > But, it still picks up Tcl/Tk libs from /usr/lib64, even though the ones we > need are right there in the named library dir: > > % ls $HOME/devel/8.4/prefix/lib > libtcl8.4.so libtk8.4.so tcl8.4 tk8.4 > libtclstub8.4.a libtkstub8.4.a tclConfig.sh tkConfig.sh Hmm. I set the _environment variables_ CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH and that works for me whenever I want to find something installed in a non-standard path. For example, right now I have software@raven> printenv |grep CMAKE CMAKE_LIBRARY_PATH=/home/software/qhull/install/lib:/home/software/libharu/install/lib:/home/software/test_fake_tcltk/install/lib CMAKE_INCLUDE_PATH=/home/software/qhull/install/include:/home/software/libharu/install/include:/usr/lib/gcc/x86_64-linux-gnu/4.3/include:/home/software/test_fake_tcltk/install/include/tcl8.4 where I have appended /home/software/test_fake_tcltk/install variants of the library and include paths. That test directory is set up as follows: /home/software/test_fake_tcltk/install /home/software/test_fake_tcltk/install/bin /home/software/test_fake_tcltk/install/bin/tclsh /home/software/test_fake_tcltk/install/lib /home/software/test_fake_tcltk/install/lib/libitk3.2.so /home/software/test_fake_tcltk/install/lib/libtk8.4.so /home/software/test_fake_tcltk/install/lib/libtcl8.4.so /home/software/test_fake_tcltk/install/lib/libitcl3.2.so /home/software/test_fake_tcltk/install/include /home/software/test_fake_tcltk/install/include/tcl8.4 /home/software/test_fake_tcltk/install/include/tcl8.4/itclDecls.h /home/software/test_fake_tcltk/install/include/tcl8.4/tcl.h [...] where everything in bin and lib is a symlink to the system version and everything in tcl8.4 was generated by "cp -a" from the system version. I also made sure /home/software/test_fake_tcltk/install/bin/tclsh was the first version on my PATH. Here is the relevant cmake output for this test setup: -- Looking for include paths and libraries for Tcl/Tk -- Found Tclsh: /home/software/test_fake_tcltk/install/bin/tclsh -- Found TCL: /home/software/test_fake_tcltk/install/lib/libtcl8.4.so -- Found TCLTK: /home/software/test_fake_tcltk/install/lib/libtcl8.4.so -- Found TK: /home/software/test_fake_tcltk/install/lib/libtk8.4.so -- Looking for include paths and libraries for Tcl/Tk - found -- Looking for tclsh -- Looking for tclsh - found -- TCL_TCLSH = /home/software/test_fake_tcltk/install/bin/tclsh -- TCL_INCLUDE_PATH = /home/software/test_fake_tcltk/install/include/tcl8.4 -- TCL_LIBRARY = /home/software/test_fake_tcltk/install/lib/libtcl8.4.so -- Looking for itcl.h -- Looking for itcl.h - found -- Looking for itcl library -- Looking for itcl library - found -- ITCL_INCLUDE_PATH = /home/software/test_fake_tcltk/install/include/tcl8.4 -- ITCL_LIBRARY = /home/software/test_fake_tcltk/install/lib/libitcl3.2.so -- TK_INCLUDE_PATH = /home/software/test_fake_tcltk/install/include/tcl8.4;/usr/include -- TK_LIBRARY = /home/software/test_fake_tcltk/install/lib/libtk8.4.so;/usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libX11.so;/usr/lib/libXext.so -- Looking for itk.h -- Looking for itk.h - found -- Looking for itk library -- Looking for itk library - found -- ITK_INCLUDE_PATH = /home/software/test_fake_tcltk/install/include/tcl8.4 -- ITK_LIBRARY = /home/software/test_fake_tcltk/install/lib/libitk3.2.so So cmake finds the special /home/software/test_fake_tcltk/install location with ease. The documentation also says that the cmake options CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH (which you have used) play the same role as the CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH environment variables so once you make the syntax correction I suggested above, and if your special version of the Tcl and Tk libraries are in the same relative paths as in /home/software/test_fake_tcltk/install above, then I believe everything should work for you. But if it doesn't, please try the environment variable approach because I _know_ from the above experiment that it should work. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-12 20:31:10
|
Alan W. Irwin writes: > On 2010-05-12 11:22-0500 Geoffrey Furnish wrote: > > BTW, taking a cue from the wiki, I added some options on the cmake line > > like this: > > > > % cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix > -DCMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include > -DCMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib .. > > That CMAKE_INCLUDE_PATH is incorrect; you should append /tcl8.4 to it. Just to be clear, the named directory did hold the Tcl headers: [furnish@ziffy]~% ls $HOME/devel/8.4/prefix/include tclDecls.h tcl.h tclPlatDecls.h tkDecls.h tk.h tkPlatDecls.h So, I don't really agree this was wrong. It is unarguable, however, that it was insufficient, which I guess is the part that mystifies me. In the end, what I stumbled my way into, which did "work", was this: cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix -DCMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include -DCMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib -DTCL_LIBRARY=$HOME/devel/8.4/prefix/lib/libtcl8.4.so -DTK_LIBRARY=$HOME/devel/8.4/prefix/lib/libtk8.4.so -DBUILD_TEST=on .. When I forcibly set the Tcl/Tk libraries in this way, I got what I needed to debug the problem. I really don't want to sound tooooo curmudgeonly here. I know the CBS has done us a lot of good by incorporating so many platforms into one system, which were not previously served by a single build system. And I know people have put a huge amount of work into making it what it is today. But I do wish it behaved more, well, I suppose any adjective here would sound inflamatory. Maybe best to just say, ... more ... according to my own expectations. And what would that mean? Well, as I showed at the start of this post, all I wanted to do was build PLplot against a different Tcl/Tk than what was installed on my system. So what did I do? I compiled Tcl and Tk and installed them to a custom, non-default prefix. Then I ran PLplot's cmake configuration, and told it the prefix I wanted it to install to. I *expect* it to undesrstand that the named prefix is the one it's supposed to play with. But what it did, was ignored (mostly) my prefix, and continued to use system components. I find this behavior to be many things, including at least, surprising, perplexing, annoying and exasperating. It is also different than how PLplot's old configuration system used to work. Over the last three years, my experience with the CBS has been that it is so hard to configure, that I normally record my configurations in shell scripts, and then run those scripts whenever I want to compile up a new PLplot. My personal opinion is that the CBS is almost unusable in a manual mode. Okay, I used it manually today, with numerous errors and missteps along the way. For debugging, I guess it's good enough. But the point is, look at how long the command line had to become, before it finally did the simple thing I wanted, of using the components found in a named prefix construction zone. I will keep writing my multi-line cmake invocation scripts, and I'm sure I can get by that way. But I do think PLplot would be more accessible to more people, if a shorter/simpler command line would get it to do the simple things that developers want. In my opinion, anything found in the installation prefix, should be the default. Package specific overides are okay, but shouldn't be required to find things in the installation prefix. And having it use the system installed packages for things it doesn't find in the installation prefix zone is okay, but it should be possible to turn that off. So, to me, a cmake invocation line should look like: % cmake --prefix=/where/I/put/my/stuff or maybe % cmake --prefix=/where/I/put/my/stuff --prefix-only to say that I don't want it to use anything not found in my prefix. Then, developers could get *exactly* what they want, for any given application, by simply constructing their prefix (of which most things going in there will be autoconf based, and use "configure --prefix=/some/where"), and then configuring PLplot against that. This proposed --prefix-only flag would control whether it would add in capabilities found from elsewhere on the system, or not. Mostly I would want not, but I could see that maybe more people would want so than not, so that not should not be the default for that switch. If cmake can't be made to use autoconf-like command line switches like "--prefix=", well, okay, but it still shouldn't take more than one token to tell PLplot's cmake where you want it to find stuff that is all located in the same prefix into which PLplot is being told to install itself. -Geoff |
From: Werner S. <sm...@ia...> - 2010-05-12 20:46:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Geoffrey, On 5/12/10 10:30 PM, Geoffrey Furnish wrote: > Alan W. Irwin writes: >> On 2010-05-12 11:22-0500 Geoffrey Furnish wrote: >>> BTW, taking a cue from the wiki, I added some options on the >>> cmake line like this: >>> >>> % cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix >> -DCMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include >> -DCMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib .. >> >> That CMAKE_INCLUDE_PATH is incorrect; you should append /tcl8.4 to >> it. > > Just to be clear, the named directory did hold the Tcl headers: > > [furnish@ziffy]~% ls $HOME/devel/8.4/prefix/include tclDecls.h tcl.h > tclPlatDecls.h tkDecls.h tk.h tkPlatDecls.h > > So, I don't really agree this was wrong. It is unarguable, > however,> that it was insufficient, which I guess is the part that > mystifies me. > > In the end, what I stumbled my way into, which did "work", was this:> > cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix > -DCMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include > -DCMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib > -DTCL_LIBRARY=$HOME/devel/8.4/prefix/lib/libtcl8.4.so > -DTK_LIBRARY=$HOME/devel/8.4/prefix/lib/libtk8.4.so -DBUILD_TEST=on > .. I think there is a misunderstanding. CMAKE_INSTALL_PREFIX is the prefix used to install the program you're configuring, this doesn't set the path, where cmake looks for libraries: pico:examples smekal$ cmake --help-variable CMAKE_INSTALL_PREFIX cmake version 2.8.1 CMAKE_INSTALL_PREFIX Install directory used by install. If "make install" is invoked or INSTALL is built, this directory is pre-pended onto all install directories. This variable defaults to /usr/local on UNIX and c:/Program Files on Windows. What you are looking for is CMAKE_PREFIX_PATH: pico:examples smekal$ cmake --help-variable CMAKE_PREFIX_PATH cmake version 2.8.1 CMAKE_PREFIX_PATH Path used for searching by FIND_XXX(), with appropriate suffixes added. Specifies a path which will be used by the FIND_XXX() commands. It contains the "base" directories, the FIND_XXX() commands append appropriate subdirectories to the base directories. So FIND_PROGRAM() adds /bin to each of the directories in the path, FIND_LIBRARY() appends /lib to each of the directories, and FIND_PATH() and FIND_FILE() append /include . By default it is empty, it is intended to be set by the project. See also CMAKE_SYSTEM_PREFIX_PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, CMAKE_PROGRAM_PATH. This option is what you described below, what you would like cmake can do. I can do that already. Please try it. Regards, Werner > > When I forcibly set the Tcl/Tk libraries in this way, I got what I > needed to debug the problem. > > I really don't want to sound tooooo curmudgeonly here. I know the > CBS has done us a lot of good by incorporating so many platforms > into one system, which were not previously served by a single build > system. And I know people have put a huge amount of work into > making it what it is today. > > But I do wish it behaved more, well, I suppose any adjective here > would sound inflamatory. Maybe best to just say, ... more ... > according to my own expectations. > > And what would that mean? Well, as I showed at the start of this > post, all I wanted to do was build PLplot against a different Tcl/Tk > than what was installed on my system. So what did I do? I compiled > Tcl and Tk and installed them to a custom, non-default prefix. Then > I ran PLplot's cmake configuration, and told it the prefix I wanted > it to install to. I *expect* it to undesrstand that the named prefix > is the one it's supposed to play with. But what it did, was ignored > (mostly) my prefix, and continued to use system components. I find > this behavior to be many things, including at least, surprising, > perplexing, annoying and exasperating. It is also different than > how PLplot's old configuration system used to work. > > Over the last three years, my experience with the CBS has been that > it is so hard to configure, that I normally record my configurations > in shell scripts, and then run those scripts whenever I want to > compile up a new PLplot. My personal opinion is that the CBS is > almost unusable in a manual mode. Okay, I used it manually today, > with numerous errors and missteps along the way. For debugging, I > guess it's good enough. But the point is, look at how long the > command line had to become, before it finally did the simple thing I > wanted, of using the components found in a named prefix > construction zone. > > I will keep writing my multi-line cmake invocation scripts, and I'm > sure I can get by that way. But I do think PLplot would be more > accessible to more people, if a shorter/simpler command line would > get it to do the simple things that developers want. > > In my opinion, anything found in the installation prefix, should be > the default. Package specific overides are okay, but shouldn't be > required to find things in the installation prefix. And having it > use the system installed packages for things it doesn't find in the > installation prefix zone is okay, but it should be possible to turn > that off. So, to me, a cmake invocation line should look like: > > % cmake --prefix=/where/I/put/my/stuff > > or maybe > > % cmake --prefix=/where/I/put/my/stuff --prefix-only > > to say that I don't want it to use anything not found in my prefix. > > Then, developers could get *exactly* what they want, for any given > application, by simply constructing their prefix (of which most > things going in there will be autoconf based, and use "configure > --prefix=/some/where"), and then configuring PLplot against that. > This proposed --prefix-only flag would control whether it would add > in capabilities found from elsewhere on the system, or not. Mostly > I would want not, but I could see that maybe more people would want > so than not, so that not should not be the default for that switch. > > If cmake can't be made to use autoconf-like command line switches > like "--prefix=", well, okay, but it still shouldn't take more than > one token to tell PLplot's cmake where you want it to find stuff > that is all located in the same prefix into which PLplot is being > told to install itself. > > -Geoff > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ Plplot-devel mailing > list Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (GPG: EDCAF4A79) 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL6xOzAAoJEG1QQcXtyvSnNk0H/jcO9V+Pc2cOmhX9DAsitTgR Sab5fSTouUrOhhNXjgz+LNH4+RI3xFMjJV0ByGv/6ttGcdiQKfrs8k0eGWqLeaZS th4O4qj7Ig6TZ0PabQqYrnDVTTU/dgVAom6pB5mTj+VmFFF/cpdbb5HqPF4OPHyT IgaOO23EUEF2m94aBwfMzZo67EwKA3n3dwlflOXXIhFg2bbENf+aNqaoRHGS7cR4 RgRJYvaRXS4nfF67iV/z/vQmxmsn09SO7Vht2F60oVYTTZX9hzmBBYzKkui0KiqF H9y5+M11ZCf1iPCvcdwdox94inrMo7d/4G4GqunN1Ae0fmCtfVsbsG+/AhzEM6g= =Zl7k -----END PGP SIGNATURE----- |
From: Geoffrey F. <geo...@at...> - 2010-05-12 20:55:24
|
Werner Smekal writes: > Hi Geoffrey, > > On 5/12/10 10:30 PM, Geoffrey Furnish wrote: > > Alan W. Irwin writes: > >> On 2010-05-12 11:22-0500 Geoffrey Furnish wrote: > >>> BTW, taking a cue from the wiki, I added some options on the > >>> cmake line like this: > >>> > >>> % cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix > >> -DCMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include > >> -DCMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib .. > >> > >> That CMAKE_INCLUDE_PATH is incorrect; you should append /tcl8.4 to > >> it. > > > > Just to be clear, the named directory did hold the Tcl headers: > > > > [furnish@ziffy]~% ls $HOME/devel/8.4/prefix/include tclDecls.h tcl.h > > tclPlatDecls.h tkDecls.h tk.h tkPlatDecls.h > > > > So, I don't really agree this was wrong. It is unarguable, > > however,> that it was insufficient, which I guess is the part that > > mystifies me. > > > > In the end, what I stumbled my way into, which did "work", was this:> > > cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix > > -DCMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include > > -DCMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib > > -DTCL_LIBRARY=$HOME/devel/8.4/prefix/lib/libtcl8.4.so > > -DTK_LIBRARY=$HOME/devel/8.4/prefix/lib/libtk8.4.so -DBUILD_TEST=on > > .. > > I think there is a misunderstanding. CMAKE_INSTALL_PREFIX is the prefix > used to install the program you're configuring, this doesn't set the > path, where cmake looks for libraries: > > pico:examples smekal$ cmake --help-variable CMAKE_INSTALL_PREFIX > cmake version 2.8.1 > CMAKE_INSTALL_PREFIX > Install directory used by install. > > If "make install" is invoked or INSTALL is built, this directory is > pre-pended onto all install directories. This variable defaults to > /usr/local on UNIX and c:/Program Files on Windows. > > > What you are looking for is CMAKE_PREFIX_PATH: > > > pico:examples smekal$ cmake --help-variable CMAKE_PREFIX_PATH > cmake version 2.8.1 > CMAKE_PREFIX_PATH > Path used for searching by FIND_XXX(), with appropriate suffixes > added. > > Specifies a path which will be used by the FIND_XXX() commands. It > contains the "base" directories, the FIND_XXX() commands append > appropriate subdirectories to the base directories. So > FIND_PROGRAM() > adds /bin to each of the directories in the path, FIND_LIBRARY() > appends /lib to each of the directories, and FIND_PATH() and > FIND_FILE() append /include . By default it is empty, it is intended > to be set by the project. See also CMAKE_SYSTEM_PREFIX_PATH, > CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, CMAKE_PROGRAM_PATH. > > > This option is what you described below, what you would like cmake can > do. I can do that already. Please try it. Okay, thanks. I just tried this: % cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix -DCMAKE_PREFIX_PATH=$HOME/devel/8.4/prefix .. |& tee cmake.out ... -- Looking for include paths and libraries for Tcl/Tk -- Found Tclsh: /home/furnish/devel/8.4/prefix/bin/tclsh -- Found TCL: /usr/lib64/libtcl.so -- Found TCLTK: /usr/lib64/libtcl.so -- Found TK: /usr/lib64/libtk.so -- Looking for include paths and libraries for Tcl/Tk - found -- Looking for tclsh -- Looking for tclsh - found -- TCL_TCLSH = /home/furnish/devel/8.4/prefix/bin/tclsh -- TCL_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include -- TCL_LIBRARY = /usr/lib64/libtcl.so -- Itcl not available or not compatible with current Tcl shell -- TK_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include;/usr/include -- TK_LIBRARY = /usr/lib64/libtk.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so I would say that did not work right. Notice that it again is chosing the libs in /usr/lib64, which are the system libs, not the ones in the custom prefix. Or, maybe I did the cmake invocation wrong (again, argh). -Geoff |
From: Werner S. <sm...@ia...> - 2010-05-12 21:20:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Geoffrey, > > Okay, thanks. I just tried this: > > % cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix -DCMAKE_PREFIX_PATH=$HOME/devel/8.4/prefix .. |& tee cmake.out > ... > -- Looking for include paths and libraries for Tcl/Tk > -- Found Tclsh: /home/furnish/devel/8.4/prefix/bin/tclsh > -- Found TCL: /usr/lib64/libtcl.so > -- Found TCLTK: /usr/lib64/libtcl.so > -- Found TK: /usr/lib64/libtk.so > -- Looking for include paths and libraries for Tcl/Tk - found > -- Looking for tclsh > -- Looking for tclsh - found > -- TCL_TCLSH = /home/furnish/devel/8.4/prefix/bin/tclsh > -- TCL_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include > -- TCL_LIBRARY = /usr/lib64/libtcl.so > -- Itcl not available or not compatible with current Tcl shell > -- TK_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include;/usr/include > -- TK_LIBRARY = /usr/lib64/libtk.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so > > I would say that did not work right. Notice that it again is chosing the > libs in /usr/lib64, which are the system libs, not the ones in the custom > prefix. Or, maybe I did the cmake invocation wrong (again, argh). > > -Geoff I think it has something to do with these lines FindTCL.cmake FIND_LIBRARY(TCL_LIBRARY NAMES tcl tcl${TK_LIBRARY_VERSION} tcl${TCL_TCLSH_VERSION} tcl${TK_WISH_VERSION} tcl86 tcl8.6 tcl85 tcl8.5 tcl84 tcl8.4 tcl83 tcl8.3 tcl82 tcl8.2 tcl80 tcl8.0 PATHS ${TCLTK_POSSIBLE_LIB_PATHS} ) It tries to find libraries with that names in that order, where TCLTK_POSSIBLE_LIB_PATHS are paths found with the help of tclsh and system paths are always there. From a former email it seems, that you don't have libtcl.so in your devel path, only libtcl8.4.so. But cmake finds libtcl.so in a system path, this may be the reason for the mixup. Could you try to add a symlink to libtcl8.4.so (same with tk)? Does this work? I don't know too much about the naming conventions of linux libraries. If this is a flaw of the FindTCL script, we should post a bug report to the cmake list. HTH, Werner - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (GPG: EDCAF4A79) 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL6xurAAoJEG1QQcXtyvSn1UAH/RkdJNR6lY0ajPf3f15I2K5n 9Wtg5MbFkifMBkcerk/phBVxUiBXbxNfW9VG1zBGNQaJ+84Jwa276eLm0HT6DiMs plBIfE3o7zRtN3iVd3Klu3MX1Q+S62Oxu9mcbRwQzZQ65eR/ELmSo5S2wjhuuaHf RE23cvUMGPWQmH92+HY3Rb52QXaE564geRORogVyW6ZFkT9nwqbKWBOqRGJkwZB+ cr8BRB3n8iDOw/hR2Jy6V4SNKg7lGUCUMsDPMlUYB4qyifA1R5obpUI9okXsJQ/K qwQNsUx4Vvw7pGOMd2D8yhFm2Y1DPkBPQNBF/SyqjI8JBetucx5uPWGgODB/SjE= =i6HS -----END PGP SIGNATURE----- |
From: Geoffrey F. <geo...@at...> - 2010-05-12 22:41:06
|
Werner Smekal writes: > I think it has something to do with these lines FindTCL.cmake > > FIND_LIBRARY(TCL_LIBRARY > NAMES > tcl > tcl${TK_LIBRARY_VERSION} tcl${TCL_TCLSH_VERSION} tcl${TK_WISH_VERSION} > tcl86 tcl8.6 > tcl85 tcl8.5 > tcl84 tcl8.4 > tcl83 tcl8.3 > tcl82 tcl8.2 > tcl80 tcl8.0 > PATHS ${TCLTK_POSSIBLE_LIB_PATHS} > ) > > It tries to find libraries with that names in that order, where > TCLTK_POSSIBLE_LIB_PATHS are paths found with the help of tclsh and > system paths are always there. From a former email it seems, that you > don't have libtcl.so in your devel path, only libtcl8.4.so. But cmake > finds libtcl.so in a system path, this may be the reason for the mixup. > Could you try to add a symlink to libtcl8.4.so (same with tk)? Does this > work? > > I don't know too much about the naming conventions of linux libraries. > If this is a flaw of the FindTCL script, we should post a bug report to > the cmake list. In my opinion, all possible versions should be searched for within the installation prefix zone. Then all possible versions should be searched for in other zones. And it should be possible (and easy) to prevent that last step. -Geoff |
From: Werner S. <sm...@ia...> - 2010-05-13 08:26:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > In my opinion, all possible versions should be searched for within the > installation prefix zone. > > Then all possible versions should be searched for in other zones. > > And it should be possible (and easy) to prevent that last step. You can easily do that by providing your own FindTCL.cmake. You can prevent that system directories are searched. If you found nothing you can then include them. Most of these Findxxx.cmake modules are user provided (although FindTCL.cmake is provided by kitware, the makers of cmake). But it's easy to change the modules according to ones needs and then let cmake use them instead of the standard one. Or, if you think this is really a major flaw (which I don't think, since the module will work for 99% of all developers), you can submit a bug report to the cmake mailing list. Regards, Werner > > -Geoff > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (GPG: EDCAF4A79) 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL67eyAAoJEG1QQcXtyvSn6VkH/3+bv1bdNndmciJYUf5XfnQ+ RRwXOaifMVUZFQEfzohoIgLSRkHpLiA+rw1zIBmF9ssrVeLUX/6DNZcG4upwVGOs 32XCvP2auMkDqoZ1g8pE9RPaOBOmXuj7sdDFAN2Qz//PAvh573zZK2rbGcbhXoR+ ygOcmZH0r7zmvD/W7UO7IDGyqtF/ZW/p67ClhyQt0hFgM5ZnBAL0+AkGyjuIr6Dm w+fVOzrKWjak3IpusaCDwGtMOgnQ5oasLbkySlKEeADLbMjDSUxyoWdIfgCswMn+ 66aEWL6KDRdZ9h1+l4DJQyIa7qdJwWYLLbzwhqxp+jI5DyWVZ0b8BhkDcMlxM3k= =ryIs -----END PGP SIGNATURE----- |
From: Alan W. I. <ir...@be...> - 2010-05-12 23:26:10
|
On 2010-05-12 23:20+0200 Werner Smekal wrote: > FIND_LIBRARY(TCL_LIBRARY > NAMES > tcl > tcl${TK_LIBRARY_VERSION} tcl${TCL_TCLSH_VERSION} tcl${TK_WISH_VERSION} > tcl86 tcl8.6 > tcl85 tcl8.5 > tcl84 tcl8.4 > tcl83 tcl8.3 > tcl82 tcl8.2 > tcl80 tcl8.0 > PATHS ${TCLTK_POSSIBLE_LIB_PATHS} > ) > > It tries to find libraries with that names in that order, where > TCLTK_POSSIBLE_LIB_PATHS are paths found with the help of tclsh and > system paths are always there. From a former email it seems, that you > don't have libtcl.so in your devel path, only libtcl8.4.so. But cmake > finds libtcl.so in a system path, this may be the reason for the mixup. > Could you try to add a symlink to libtcl8.4.so (same with tk)? Does this > work? But if you look in the documentation of find_library, PATHS is about the last thing looked at (#6 as opposed to #1 CMAKE_LIBRARY_PATH set with cmake option and #2 CMAKE_LIBRARY_PATH set with environment variable). So I believe the net result should be it looks for each of the names in turn, e.g., libtcl.so, ..., libtcl8.4.so,... etc., in Geoffrey's CMAKE_LIBRARY_PATH that he specified on the command line, and only if that fails, would the other alternative search areas (including PATHS as #6) be searched for. Just from an efficiency perspective, makes sense to go through the complete list of names for each search location rather than searching in a lot of different locations for each name. But in any case, I assume the names are traversed for each search location in turn since CMAKE_LIBRARY_PATH is supposed to be all about giving user's control of the search. If instead, the list of possible locations were searched for each name, than a configuration like above would not allow users to control what is found in some cases, and I think there would be huge complaints on the CMake list about that if it were possible. Once Geoffrey responds to my further suggestions about expanding $HOME and/or using the environment variable approach, we will likely know for sure whether my above assumption is correct. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-05-13 18:38:19
|
On 2010-05-12 23:20+0200 Werner Smekal wrote: > I think it has something to do with these lines FindTCL.cmake > > FIND_LIBRARY(TCL_LIBRARY > NAMES > tcl > tcl${TK_LIBRARY_VERSION} tcl${TCL_TCLSH_VERSION} tcl${TK_WISH_VERSION} > tcl86 tcl8.6 > tcl85 tcl8.5 > tcl84 tcl8.4 > tcl83 tcl8.3 > tcl82 tcl8.2 > tcl80 tcl8.0 > PATHS ${TCLTK_POSSIBLE_LIB_PATHS} > ) Hi Werner: You were absolutely right. I now have a simple test case (see my recent post to the cmake list) that replicates the issue. The net effect is if alternate names are put into the find command as above in decreasing version order, then as Geoff found out you cannot access an older version than the system version in non-standard locations using CMAKE_LIBRARY_PATH or any other of the standard means of affecting the library search order. For example, for my really simple test case that only involved one FIND_LIBRARY command I could not find libtcl8.3 in a non-standard location using CMAKE_LIBRARY_PATH when my system version was libtcl8.4. Note, this is not just an issue with FindTCL.cmake. It is an issue with all FIND_XXX commands that specify alternate names so it could affect a large number of different find modules. I view this behaviour as a serious CMake bug since accessing old versions in non-standard locations is an important (although minority) use case for software testers so they can replicate reported bugs for older versions of dependent libraries (as Geoff was doing). The cmake issue can be addressed by swapping the current inner loop over alternate locations with the current outer loop over alternate names that is presumably used by the CMake code that implements the FIND_XXX commands. I suspect large changes in code may be involved to swap those two loops so I don't know how motivated the CMake developers will be to fix the issue, but we will see. Meanwhile, I am thankful that Geoff found a workaround for this cmake bug so he could access Tcl8.4 in a non-standard location and replicate and fix the Tcl8.4 issue I found for example 19. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-15 16:39:56
Attachments:
proof
|
Werner Smekal writes: > I think there is a misunderstanding. CMAKE_INSTALL_PREFIX is the prefix > used to install the program you're configuring, this doesn't set the > path, where cmake looks for libraries: > > pico:examples smekal$ cmake --help-variable CMAKE_INSTALL_PREFIX > cmake version 2.8.1 > CMAKE_INSTALL_PREFIX > Install directory used by install. > > If "make install" is invoked or INSTALL is built, this directory is > pre-pended onto all install directories. This variable defaults to > /usr/local on UNIX and c:/Program Files on Windows. > > > What you are looking for is CMAKE_PREFIX_PATH: > > > pico:examples smekal$ cmake --help-variable CMAKE_PREFIX_PATH > cmake version 2.8.1 > CMAKE_PREFIX_PATH > Path used for searching by FIND_XXX(), with appropriate suffixes > added. > > Specifies a path which will be used by the FIND_XXX() commands. It > contains the "base" directories, the FIND_XXX() commands append > appropriate subdirectories to the base directories. So > FIND_PROGRAM() > adds /bin to each of the directories in the path, FIND_LIBRARY() > appends /lib to each of the directories, and FIND_PATH() and > FIND_FILE() append /include . By default it is empty, it is intended > to be set by the project. See also CMAKE_SYSTEM_PREFIX_PATH, > CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, CMAKE_PROGRAM_PATH. > > > This option is what you described below, what you would like cmake can > do. I can do that already. Please try it. While I was hopeful when I read this, that there would be a way to do what I need using cmake, it turns out that in actual fact the above documented options do not work as advertised. I have attached a script called "proof", which may be used to see exactly what I am talking about. I really do not have the bandwidth to answer a lot of questions about what is or isn't on my system, in my directories, etc. Instead, please just run this script, and it will become abundantly clear that cmake does not work as described in the above system help messages. I suggest making a directory ~/proof, and putting this script in there. Then do: cd ~/proof ./proof fetch ./proof prep ./proof check Thes commands will fetch you a pristine python, and build it, installing it into your ~/proof/prefix. This will include the numpy which is needed by plplot, and will prove that the so-built python does include working numpy. If you try to execute the ~/proof/check.py script using a non-numpy-equipped python, such as the one on my system, you'll get a different result, such as: --------------------- ziffy:~/proof pwd /home/furnish/proof ziffy:~/proof which python /usr/bin/python ziffy:~/proof python check.py Traceback (most recent call last): File "check.py", line 1, in <module> import numpy ImportError: No module named numpy --------------------- Then do: ./proof config ./proof altcfg Both of which will demonstrate very conclusively that cmake does NOT allow you to override the system components, unless one were to go to the trouble of rewriting some of the cmake modules, which, I suppose, it is now time for me to start doing if I am to have any hope of achieving the objective of building a plplot against a custom, non-system-default python. Note that this is a python 2.7 beta strain. 2.7 isn't in the list of programs in cmake's Module/FindPythonInterp.cmake. However, "python" is in the list (at the end), and should be found. And if the system path was really being overriden, then there is no way it should be coming back with /usr/bin/python2.6 when the system path has been set to /bogus, and there is no /bogus/usr/bin/anything on my system (and probably not on yours either :-). > ziffy:~ ls /bogus > ls: cannot access /bogus: No such file or directory On my system, both config and altcfg report, during the cmake configuration: ------------------------------------------------ -- Found PythonInterp: /usr/bin/python2.6 -- Found PythonLibs: /usr/lib64/python2.6/config/libpython2.6.so Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: No module named numpy -- WARNING: Numeric header not found. Disabling python bindings ------------------------------------------------ followed ultimately by: ENABLE_python: OFF ENABLE_octave: OFF If you're default system pytyhon has the numpy installed, you might get a "success" on the final line. But unless you find a way to get cmake to find ~/proof/prefix/bin/python, I won't consider it working, since I do need a custom python to be used for my PLplot build. If you remove your system default numpy install, it will all surely start failing for you, just as for me, despite the presence of a demonstrably numpy-equipped python in your local build zone (~/proof/prefix/bin/python in this case). Finally, this broken cmake behavior exhibits under both cmake 2.6.4 and 2.8.1. -Geoff |
From: Alan W. I. <ir...@be...> - 2010-05-12 23:14:55
|
On 2010-05-12 15:30-0500 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > On 2010-05-12 11:22-0500 Geoffrey Furnish wrote: > > > BTW, taking a cue from the wiki, I added some options on the cmake line > > > like this: > > > > > > % cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix > > -DCMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include > > -DCMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib .. > > > > That CMAKE_INCLUDE_PATH is incorrect; you should append /tcl8.4 to it. > > Just to be clear, the named directory did hold the Tcl headers: > > [furnish@ziffy]~% ls $HOME/devel/8.4/prefix/include > tclDecls.h tcl.h tclPlatDecls.h tkDecls.h tk.h tkPlatDecls.h Just for completeness could you also show us the results of ls $HOME/devel/8.4/prefix/lib ? It is possible the whole issue is caused by $HOME. The shell should translate that properly for the ls command, but I wonder if it is doing that for the cmake -D option? Anyhow, if ls shows the proper libraries and headers are in the proper locations, I would try (a) expanding $HOME by hand for the cmake option and if that doesn't work (b) use the environment variable approach which I know works for me. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-12 23:56:00
|
Alan W. Irwin writes: > Just for completeness could you also show us the results of > > ls $HOME/devel/8.4/prefix/lib > > ? % ls $HOME/devel/8.4/prefix/lib libtcl8.4.so libtk8.4.so tcl8.4 tk8.4 libtclstub8.4.a libtkstub8.4.a tclConfig.sh tkConfig.sh > It is possible the whole issue is caused by $HOME. The shell should > translate that properly for the ls command, but I wonder if it is doing > that for the cmake -D option? Anyhow, if ls shows the proper libraries > and headers are in the proper locations, I would try (a) expanding $HOME > by hand for the cmake option and if that doesn't work (b) use the > environment variable approach which I know works for me. Mmmm. The shell expands $HOME for all commands, nothing special about cmake (or ls) in this case. However, just for completeness: % rm -rf * % cmake -DCMAKE_INSTALL_PREFIX=/home/furnish/devel/8.4/prefix -DCMAKE_PREFIX_PATH=/home/furnish/devel/8.4/prefix .. |& tee cmake.out ... -- Looking for include paths and libraries for Tcl/Tk -- Found Tclsh: /home/furnish/devel/8.4/prefix/bin/tclsh -- Found TCL: /usr/lib64/libtcl.so -- Found TCLTK: /usr/lib64/libtcl.so -- Found TK: /usr/lib64/libtk.so -- Looking for include paths and libraries for Tcl/Tk - found -- Looking for tclsh -- Looking for tclsh - found -- TCL_TCLSH = /home/furnish/devel/8.4/prefix/bin/tclsh -- TCL_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include -- TCL_LIBRARY = /usr/lib64/libtcl.so -- Itcl not available or not compatible with current Tcl shell -- TK_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include;/usr/include -- TK_LIBRARY = /usr/lib64/libtk.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so (which is still wrong). Finally: % rm -rf * % export CMAKE_INSTALL_PREFIX=/home/furnish/devel/8.4/prefix % export CMAKE_PREFIX_PATH=/home/furnish/devel/8.4/prefix % cmake .. |& tee cmake.out ... -- Looking for include paths and libraries for Tcl/Tk -- Found Tclsh: /home/furnish/devel/8.4/prefix/bin/tclsh -- Found TCL: /usr/lib64/libtcl.so -- Found TCLTK: /usr/lib64/libtcl.so -- Found TK: /usr/lib64/libtk.so -- Looking for include paths and libraries for Tcl/Tk - found -- Looking for tclsh -- Looking for tclsh - found -- TCL_TCLSH = /home/furnish/devel/8.4/prefix/bin/tclsh -- TCL_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include -- TCL_LIBRARY = /usr/lib64/libtcl.so -- Itcl not available or not compatible with current Tcl shell -- TK_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include;/usr/include -- TK_LIBRARY = /usr/lib64/libtk.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so Still wrong. Well, still annoying, and still requiring lots of circumvention. Wrong might not be the right word, if this is what the cmake folks intend. It's certainly wrong from my point of view, but possibly is right from the point of view of the cmake developers. My central point in all of this, is that PLplot's CBS is very aggravating for people who like to build software with very carefully composed prefix components, which should be the same on all systems. PLplot's CBS is perhaps well suited for developers who are happy to use whatever is on each system. But I'm mostly in the former category. I like to build my whole application with always exactly those components that I've qualified, and so building up the prefix is part of porting the application to another platform. PLplot's CBS makes it very difficult to practice this type of disciplined software development, because it constantly ignores what's in the target installation prefix. This makes it very hard to control exactly what is in your application. -Geoff |
From: Alan W. I. <ir...@be...> - 2010-05-13 00:40:34
|
On 2010-05-12 18:55-0500 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > Just for completeness could you also show us the results of > > > > ls $HOME/devel/8.4/prefix/lib > > > > ? > > % ls $HOME/devel/8.4/prefix/lib > libtcl8.4.so libtk8.4.so tcl8.4 tk8.4 > libtclstub8.4.a libtkstub8.4.a tclConfig.sh tkConfig.sh > > > It is possible the whole issue is caused by $HOME. The shell should > > translate that properly for the ls command, but I wonder if it is doing > > that for the cmake -D option? Anyhow, if ls shows the proper libraries > > and headers are in the proper locations, I would try (a) expanding $HOME > > by hand for the cmake option and if that doesn't work (b) use the > > environment variable approach which I know works for me. > > Mmmm. The shell expands $HOME for all commands, nothing special about cmake > (or ls) in this case. However, just for completeness: > > % rm -rf * > % cmake -DCMAKE_INSTALL_PREFIX=/home/furnish/devel/8.4/prefix -DCMAKE_PREFIX_PATH=/home/furnish/devel/8.4/prefix .. |& tee cmake.out > Finally: > > % rm -rf * > % export CMAKE_INSTALL_PREFIX=/home/furnish/devel/8.4/prefix > % export CMAKE_PREFIX_PATH=/home/furnish/devel/8.4/prefix > % cmake .. |& tee cmake.out ... Geoffrey, I should have been more specific in the test I requested. Please use the combination of the environment variables CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH pointed to the correct locations. As I have just demonstrated, that combination should work fine. And that combination has worked fine since CMake-2.4.x days. Please run the test with no interference from CMAKE_PREFIX_PATH which is something I have not tested. I realize somebody else suggested it in this thread as a possibility, and as far as I can tell from the documentation it _should_ work in the limited case where you have your headers installed in the include directory rather than subdirectories of include. But let's test with a case that I _know_ works for me to give a perfect Tcl/Tk/itcl/itk result. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <geo...@at...> - 2010-05-13 01:03:49
|
Alan W. Irwin writes: > On 2010-05-12 18:55-0500 Geoffrey Furnish wrote: > > > Alan W. Irwin writes: > > > Just for completeness could you also show us the results of > > > > > > ls $HOME/devel/8.4/prefix/lib > > > > > > ? > > > > % ls $HOME/devel/8.4/prefix/lib > > libtcl8.4.so libtk8.4.so tcl8.4 tk8.4 > > libtclstub8.4.a libtkstub8.4.a tclConfig.sh tkConfig.sh > > > > > It is possible the whole issue is caused by $HOME. The shell should > > > translate that properly for the ls command, but I wonder if it is doing > > > that for the cmake -D option? Anyhow, if ls shows the proper libraries > > > and headers are in the proper locations, I would try (a) expanding $HOME > > > by hand for the cmake option and if that doesn't work (b) use the > > > environment variable approach which I know works for me. > > > > Mmmm. The shell expands $HOME for all commands, nothing special about > > cmake (or ls) in this case. However, just for completeness: > > > > % rm -rf * > > % cmake -DCMAKE_INSTALL_PREFIX=/home/furnish/devel/8.4/prefix -DCMAKE_PREFIX_PATH=/home/furnish/devel/8.4/prefix .. |& tee cmake.out > > > Finally: > > > > % rm -rf * > > % export CMAKE_INSTALL_PREFIX=/home/furnish/devel/8.4/prefix > > % export CMAKE_PREFIX_PATH=/home/furnish/devel/8.4/prefix > > % cmake .. |& tee cmake.out > > ... > > Geoffrey, I should have been more specific in the test I requested. Please > use the combination of the environment variables CMAKE_INCLUDE_PATH and > CMAKE_LIBRARY_PATH pointed to the correct locations. As I have just > demonstrated, that combination should work fine. And that combination has > worked fine since CMake-2.4.x days. > > Please run the test with no interference from CMAKE_PREFIX_PATH which is > something I have not tested. I realize somebody else suggested it in this > thread as a possibility, and as far as I can tell from the documentation it > _should_ work in the limited case where you have your headers installed in > the include directory rather than subdirectories of include. But let's test > with a case that I _know_ works for me to give a perfect Tcl/Tk/itcl/itk > result. Alright, I think I have what you're asking for. I can't bear all this manual typing, so I've retreated to my old habits (of recording it in a script). Here's the script: % cat ../run_cmake #!/bin/sh rm -rf * env CMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix \ CMAKE_INCLUDE_PATH=$HOME/devel/8.4/prefix/include \ CMAKE_LIBRARY_PATH=$HOME/devel/8.4/prefix/lib \ cmake .. |& tee cmake.out And here's the result of running it: % ../run_cmake ... -- Looking for include paths and libraries for Tcl/Tk -- Found Tclsh: /home/furnish/devel/8.4/prefix/bin/tclsh -- Found TCL: /usr/lib64/libtcl.so -- Found TCLTK: /usr/lib64/libtcl.so -- Found TK: /usr/lib64/libtk.so -- Looking for include paths and libraries for Tcl/Tk - found -- Looking for tclsh -- Looking for tclsh - found -- TCL_TCLSH = /home/furnish/devel/8.4/prefix/bin/tclsh -- TCL_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include -- TCL_LIBRARY = /usr/lib64/libtcl.so -- Itcl not available or not compatible with current Tcl shell -- TK_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include;/usr/include -- TK_LIBRARY = /usr/lib64/libtk.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so Again, same wrong result. To humor you further, here's another take on the script (with $HOME manually substituted): % cat ../run_cmake #!/bin/sh rm -rf * env CMAKE_INSTALL_PREFIX=/home/furnish/devel/8.4/prefix \ CMAKE_INCLUDE_PATH=/home/furnish/devel/8.4/prefix/include \ CMAKE_LIBRARY_PATH=/home/furnish/devel/8.4/prefix/lib \ cmake .. |& tee cmake.out % ../run_cmake ... -- Looking for include paths and libraries for Tcl/Tk -- Found Tclsh: /home/furnish/devel/8.4/prefix/bin/tclsh -- Found TCL: /usr/lib64/libtcl.so -- Found TCLTK: /usr/lib64/libtcl.so -- Found TK: /usr/lib64/libtk.so -- Looking for include paths and libraries for Tcl/Tk - found -- Looking for tclsh -- Looking for tclsh - found -- TCL_TCLSH = /home/furnish/devel/8.4/prefix/bin/tclsh -- TCL_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include -- TCL_LIBRARY = /usr/lib64/libtcl.so -- Itcl not available or not compatible with current Tcl shell -- TK_INCLUDE_PATH = /home/furnish/devel/8.4/prefix/include;/usr/include -- TK_LIBRARY = /usr/lib64/libtk.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so Still wrong. -Geoff |