Geoffrey Furnish writes: > I'm having trouble compiling plplot on Fedora 11. I am at rev 10054. > [...] > So, it seems that plplot, with cmake 2.6.4, is wrongly concluding that > even though the tcl executables are at ~/F11/icf/bin, and the headers at > ~/F11/icf/include, and the corresponding libs are at ~/F11/icf/lib, > nevertheless, it wants to use the libs in /usr/lib64. And the above link > line shows that the lib search path is wrongly directed to /usr/lib64 > before pulling in -ltcl and -ltk. > > Any suggestions on how to counteract this, and get back to where cmake uses > the CMAKE_INSTALL_LIBDIR for resolving the needed libraries?
FWIW, I've found that I can set explicitly TCL_LIBRARY and TK_LIBRARY. So, my immediate crisis of not being able to rebuild PLplot on F11 is resolved. However, I remain concerned that autodetection is not working correctly. Or at least, not as I expect and personally consider to be "correct". I am finding cmake to be the source of a lot of trouble in working with PLplot. Besides what I've reported in this thread and other recent threads, there are other failure modes that I haven't gotten around to bringing up yet. For instance, I recently noticed that some of our old releases won't build *at all* if you have a modern cmake in your path (which you need to work with the more recent PLplot releases or svn head). So some of our historical releases are effectively unusable on more recent os distros becasue they need changes to the cmake files in order to track along with modern distros as they use more recent cmake versions. I also find it frustrating that everytime I build a new tool chain with some specific version of cmake needed to compile some particular version of plplot svn head, then one month later my toolchain is defunct because we're needing a yet newer version of cmake in order to be able to build. Putting a Python 2.6 in my prefix caused a lot of PLplot/cmake trouble a couple months ago. Now PLplot/cmake can't manage to decide to use the Tcl/Tk librareis that go with the headers it clearly does find. So more changes to the application build script to override the misfiring "autodetection" logic. Etc. I'm not irked enough to be entertaining thoughts (at least not serious thoughts) of an alternate build system at this time. But I would like to know if other developers can think of ways that we could change our approach to the use of cmake, that would result in a more stable environment? For instance, in the old system, if you wanted to change the configure script, you might've needed certain modern/recent release of autoconf, autotools, whatever. But the configure scripts themselves were--in my admittedly limited/biased experience--usually quite resilient to underlying system change. Obviously, old configure scripts wouldn't magically start finding stuff to support new PLplot features. If you wanted to add feature support you had to regenerate the configure script, which meant having certain minimum versions of the developer tools in your path. But the PLplot releasees themselves, with a single configure script, were able to do whatever they did on a range of systems, including os distro releases that appeared only after the PLplot release was cast. You didn't generally have to regenerate the configure script in order for it to do what it did in the past, on a new distro release. Is there any way we can get back to that? -Geoff ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
