Hi Geoffrey, although I can't help you with your special problem with the tcl/tk libraries, I can only comment your emails and tell you why there are problems. From my experience I can tell, that I don't have these problems you have. I'm working on several Linux distributions (Ubuntu, Red Hat Enterprise, Centos), Windows (XP) and Mac OS X and I'm quite satisfactory the way cmake is able to configure the PLplot source code. Short: I seldom have such problems you have (and I also compile 3rd party libraries on my own). The reason why I don't have problems is, that cmake is well tested and stable for all the libraries I use (and I use/test many of them supported by PLplot). When I encountered a problem I solved it, or others solved it for me. That's also you problem - you are using tcl/tk which practically nobody else use (except Arjen but on Windows). So this cmake part is not well tested. It's not well debugged.
So in my opinion it's not the fault of cmake (it's far not perfect, agreed) that you have problems, it's just that not many use that part. If you provide us with test results (what you did) we can try to improve the cmake build system for tcl/tk as well. On the other side your test case is rather specific. You are using a bleeding edge distribution - I read about this distribution of Fedora and it was called genius (because everything is so new) and totally crazy (because everything is so new ;). Using Fedora Core 11 will likely lead to problems. You are using your own tcl/tk libraries (which should work, but is special) and you're are obviously using a 64bit machine - also not well tested (though Alan and Andrew use such a system). So I would think for sure, that not everything will run perfect on such an environment. Regarding autoconfigure - I also encountered similar problems there, so I don't see much advantage here (though autoconfigure might be more stable then cmake since it's much older). E.g. try to compile gnuplot 4.0 on Mac OS X with Aquaterm. If you are using Aquaterm 1.0, no proplem, if you're using Aquaterm 1.1 (minor bug fix) it compiles but doesn't find the shared Aquaterm library, since it's called a little different. Autoconfigure didn't pick that up. PLplot is not operating in a closed environment where we have complete control over all libraries. So we can try to optimise the configure experience of our users, but there will always be a test case, where cmake will have problems to configure properly. I doubt that this will improve with autoconfigure - apart from the big disadvantage, that you'll get rid of the Windows user base as well. Regarding an alternate build system: no problem. Cmake doesn't care. So if there is one who wants to add autoconfigure scripts to PLplot the developers will gladly add this to PLplot. If someone continues to work on this. This was the reason why it was removed. Nobody maintained it. I'm also convinced that the cmake build system will further improve, so that most users of PLplot will have no problems using it. Regards, Werner On 18.06.2009, at 06:54, Geoffrey Furnish wrote: > 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 -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sme...@iap.tuwien.ac.at 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 ------------------------------------------------------------------------------ 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
