Re: [Plplot-devel] Tcl example 19
Hello, I am chiming in very late in this discussion (we had a very long weekend off in my little country at the sea and I did not feel very motivated to read my e-mail for a variety of reasons), but my idea is this: Rather than let CMake find out everything it needs to about what version of Tcl to use, why not let a small Tcl script do the job? Tcl offers enough introspection to make that happen. Here is a sketch: - The current FindTcl.cmake file is fine, as far as looking for tclsh is concerned (possibly modulo a specific tclsh that you want used). - It can then start that particular tclsh with a script that will report what libraries that tclsh shell uses (I have something of that kind already, though it will need to be adapted for this purpose) Regards, Arjen On 2010-05-13 10:26, Werner Smekal wrote: -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 Plplot-devel@lists.sourceforge.net 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: sme...@iap.tuwien.ac.at (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- -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
On Mon, May 17, 2010 at 09:27:06AM +0200, Arjen Markus wrote: Hello, I am chiming in very late in this discussion (we had a very long weekend off in my little country at the sea and I did not feel very motivated to read my e-mail for a variety of reasons), but my idea is this: Rather than let CMake find out everything it needs to about what version of Tcl to use, why not let a small Tcl script do the job? Tcl offers enough introspection to make that happen. Here is a sketch: - The current FindTcl.cmake file is fine, as far as looking for tclsh is concerned (possibly modulo a specific tclsh that you want used). - It can then start that particular tclsh with a script that will report what libraries that tclsh shell uses (I have something of that kind already, though it will need to be adapted for this purpose) Yes! In my opinion this is exactly what cmake should do. The user only has to ensure that the correct tclsh is in the path and then everything else is automatically found. With this is should be impossible to get the wrong versions of libraries or headers. Why this wasn't done in the first place I don't know. The only down side of relying on actually running an executable is that it doesn't work for cross-compilation, but in this case you expect to have to do a bit more work. Perhaps using the current approach as a fall-back is the way to go? Andrew -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
Hi Andrew, On 2010-05-17 10:09, Andrew Ross wrote: On Mon, May 17, 2010 at 09:27:06AM +0200, Arjen Markus wrote: Hello, I am chiming in very late in this discussion (we had a very long weekend off in my little country at the sea and I did not feel very motivated to read my e-mail for a variety of reasons), but my idea is this: Rather than let CMake find out everything it needs to about what version of Tcl to use, why not let a small Tcl script do the job? Tcl offers enough introspection to make that happen. Here is a sketch: - The current FindTcl.cmake file is fine, as far as looking for tclsh is concerned (possibly modulo a specific tclsh that you want used). - It can then start that particular tclsh with a script that will report what libraries that tclsh shell uses (I have something of that kind already, though it will need to be adapted for this purpose) Yes! In my opinion this is exactly what cmake should do. The user only has to ensure that the correct tclsh is in the path and then everything else is automatically found. With this is should be impossible to get the wrong versions of libraries or headers. Why this wasn't done in the first place I don't know. The only down side of relying on actually running an executable is that it doesn't work for cross-compilation, but in this case you expect to have to do a bit more work. Perhaps using the current approach as a fall-back is the way to go? I am willing to investigate this option including the fall-back. Regards, Arjen -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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 proof
Re: [Plplot-devel] Tcl example 19
-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 Plplot-devel@lists.sourceforge.net 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: sme...@iap.tuwien.ac.at (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- -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. For my big software project, I do exactly this. Compiling all my 3rd party libraries in a special directory and let cmake find it - no problems here, even if the libraries are already in the system (wxwidgets, plplot). So, it's definitely not a problem of cmake (at least not from the core), but maybe from the FindTCL.cmake module). 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. This is exactly what I'm doing with most of my projects and so far I had no problem with cmake, totally opposite, I was glad that it worked for 3 platforms practically out of the box. Regards, Werner 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 -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net 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: sme...@iap.tuwien.ac.at (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/ iQEcBAEBAgAGBQJL67jwAAoJEG1QQcXtyvSnaUUH/2ut04iXil+qse4euv90JqiK mTg2dLkP/lgLUfm28XWhkjFCuN8FJSnf2GmTeZBdat0BpnCxystEuB+G80EmKdJy oOrGMeaoRQCTlefMnJ6+ObyT5vvkgRB2gXHWiB8L3sLVZVJag2oGRyi43xJvSzs8 3QBs7oaJ3BQxhsd4kyAZ7V45c/vHItFGc5OCkMZwnBzS/dWvmuA2HwcxFIqWfFPJ jAEhL+U744OMyIlr/SKzSQ/bezxTwE3hyoQ57gH2SwFFfCx8RYrAGU/rEPUNXYax v1f52TE/kfoVbeh3p5VzlLHDJDVvJJrbVMquDxx8YYQpCSS+I13lD4KTt2ITnjA= =3tsz -END PGP SIGNATURE- -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I really hate that our CBS won't work correctly on so many OS platforms because of cmake. For cryin' out loud, Fedora 12 is the most recently released version of Fedora, and it is using cmake 2.6.4. And that's not good enough? I have to manually construct a noveau cmake just so I can build PLplot? Just earlier today I documented that our current PLplot won't configure at all on Fedora 8. Now we see that it will configure, but wrongly on Fedora 12. What's wrong with this picture? I know exactly what's wrong: cmake Are we going to update PLplot's cmake configuration files to demand cmake 2.8.x? Honestly, I think this is nuts. When you read through the mailing list, there is just a small number of problems with CBS and most of the complaints are from you. You can read through the gnuplot mailing list the last 3 months and there were much more problems with autoconf we had in the whole year. Someone changed the code so that it works for Linux and that broke the Mac OS X build and so on. Just go ahead and read. There is obviously no perfect build system. IMO cmake works extremly well, is very flexible and after you understood the basics it's very easy to set up a (cross platform) build system - I use it for all my projects. The reason tcl/tk might not work so well is, that not many people use it. It's rarely a topic on the mailing list, and e.g. I don't use it at all on all platforms, I never really test it. So it's very likely that there is a lot of room for improvement it this part of the CBS, but IMO this fact doesn't justify a basic criticism of the whole CBS - which e.g. works most of the time perfectly well, and I work exactly like you with many version of custom compiled libraries arbitrarily placed somewhere on my hard disc. Regards, Werner PS: I use several versions of cmake 2.6.3 to 2.8.1 on my 3 computers I work with and about 6 virtual computers and basically don't have problems. Installing the precompiled cmake code for Linux is btw a matter of 2 minutes. I think it would be a lot more user (and our users are all developers) friendly, if we shipped cmake modules that override all the broken behavior in cmake, so that people who have cmake in their OS distro, would be able to just use it, without having to build a toolchain just so they can compile our library. I will try to run the test with cmake 2.8.1 and report the results. But personally, a favorable result with cmake 2.8.1 doesn't really seem like good news, if it means we conclude that every PLplot developer on earth is going to have to upgrade past their distro's cmake version, just in order to compile our library (reliably). I think we ought to be looking at an internal solution. And I don't mean to interrupt the current release push with this brouhaha. Documenting it and deferring it would be okay with me in the short term. Long term, if everyone else is really so happy with cmake, then I think we need to find a way to ship enough custom overides so that people can reliably build PLplot with whatever cmake they have on a reasonably up to date distro. I realize there would be some limites. cmake 0.2.3 is not something we should support. But I really have a hard time with the idea that Fedora 12's cmake is so old that it has to be upgraded before reliable builds will work. More when I have it. -Geoff -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net 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: sme...@iap.tuwien.ac.at (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/ iQEcBAEBAgAGBQJL67ymAAoJEG1QQcXtyvSn2vsH/0WztgSZkoHb84LQn3p9PwK4 fmYGtPxoJbtWvlQ9UlGPLX6n9KvQkQsG1Rc8yaa2TABNWQq/lnTgS+reWlERyky/ b0xRdvei8PH3mrBrnPOfzMHxa7WFKGZSi6xByaFdT3rluqflUFTryW0r4iaqfqdM CvGUgf8CdC5dNSi5GRJ7r+ftCThgZeWgsftADQGIY7fkJhBd7oCJ6R4u/S421qME IJEeR/cXoosOJZXcdLuZ7FyUg9h22TAZPVWdnkIc6PdNZ/UkIQVoai7KS3It975i khmiTx1gMsIsrqIgfu+OJkdPVTn6VeXTkfFlm5iPYECXxR0ZOHUsQLhKcAJXjn4= =M6Fd -END PGP SIGNATURE- -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 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
__
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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.4tk8.4 libtclstub8.4.a libtkstub8.4.a tclConfig.sh tkConfig.sh -Geoff -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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?
Well, so I went to a Fedora 8 system which has Tcl 8.4, and checked out the
code there. Won't build because F8 uses cmake 2.4.8.
Instead of trying to build a new developer toolchain on that computer, I
decided to come back to my Fedora 12 system, where I did the x19 development
work, and which uses Tcl/Tk 8.5 as you surmised. And I pulled down Tcl/Tk
8.4.19, built them, installed to a local prefix, and then reran cmake with
that prefix/bin dir in my path.
cmake found only the Tcl/Tk in /usr/{bin|lib}. So then I make a softlink in
my Tcl/Tk 8.4 prefix/bin dir, from tclsh8.4 to tclsh, rm'd everything in my
plplot build tree, and reran the cmake. This time I got:
% cmake -DCMAKE_INSTALL_PREFIX=$HOME/devel/8.4/prefix ..
...
-- 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
So, it found the tclsh in my path, correctly matched the proper Tcl include
path, but picked up the Tcl/Tk libs in /usr/lib64, which are the system 8.5
variants.
Question: What is the right way to tell PLplot CBS to use the Tcl/Tk in a
particular non-default location?
Opinion: PLplot should preferentially select components from any supplied
prefix, which for our CBS, is apparently specified via
-DCMAKE_INSTALL_PREFIX. Anything found there, should supercede any other
things which may be lying around on the system.
Opinion: Under no circumstances should PLplot CBS miscombine includes and
libs for any component, from disparate locations in the filesystem.
-Geoff
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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.4tk8.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 softw...@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 =
Re: [Plplot-devel] Tcl example 19
On Wed, May 12, 2010 at 11:22:20AM -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 .. ... -- 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.4tk8.4 libtclstub8.4.a libtkstub8.4.a tclConfig.sh tkConfig.sh The handling of multiple versions of software is something I really dislike about the current cmake Find* scripts. I'd really rather it was intelligent. Once tclsh has been found cmake could easily do a tcl version check and only search for versions which matched that. I've had lots of problems when using tcl8.4 on a system with tcl8.5 also installed. Andrew -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
On 2010-05-12 12:36-0500 Geoffrey Furnish wrote: Alan W. Irwin writes: If you try Tcl-8.4 do you get the same error? Thanks for your report. Yes I eventually did duplicate the error, and have now fixed it. I had no idea that lassign was introduced in Tcl 8.5. Thanks, Geoffrey. It now works here for me as well. I am still interested in the difficulties you had in specifying your non-standard Tcl/Tk install location so I hope you will also respond to the post (including a working test case) I just made about that. 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 __ -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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: [furn...@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 to 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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: [furn...@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 -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
-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: sme...@iap.tuwien.ac.at (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-
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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: [furn...@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 __ -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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
__
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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.4tk8.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 -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
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.4tk8.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 __ -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl example 19
Alan W. Irwin writes: To take this further could you please try building cmake-2.8.1 (see directions at http://cmake.org/cmake/resources/software.html) and use that version instead for the above test if that is not what you are already doing? That's the version I use for my testing with cmake-2.8.x these days. [furn...@ziffy]~/devel/pldev/plplot/bd3% which cmake ~/devel/pldev/tools/bin/cmake [furn...@ziffy]~/devel/pldev/plplot/bd3% cmake --version cmake version 2.8.1 [furn...@ziffy]~/devel/pldev/plplot/bd3% ../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 So, same wrong result. If cmake-2.8.1 built from kitware source shows the bad find result you demonstrated above, then I will take this up further with the cmake list. Thanks. I hope it goes well. But I also hope we can find a way to make PLplot builds work according to reasonable expectations, without having to bump everyone up to cmake 2.8.2... -Geoff -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Tcl example 19
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 __ -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
