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 ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
