Alan W. Irwin writes: > I think the explanation must be you are running into previously unknown > build issues because you are using the build system for situations > (platforms and library version sets) the rest of us don't have access > to. By definition that class of build-system bugs is hard for the rest of > us to replicate. Probably the best thing for you to do for this case is to > sit down and learn CMake deeply enough so you can fix these problems for > yourself. That is actually quite easy to do, and I would be happy to help > you with that deeper CMake learning process if you run into anything you > cannot understand for yourself.
Alan W. Irwin writes: > CMake finds all the Tcl/Tk components using the logic in > > $prefix/share/cmake-2.6/Modules/FindTCL.cmake where $prefix is the > installation prefix for the CMake install. Where it searches is > controlled by the CMake variable TCLTK_POSSIBLE_LIB_PATHS. It looks like > that list of paths includes references to the locations where tclsh and > wish are found. From what you said, those should be on your PATH so it > appears something is going wrong with the CMake logic to relate library > location and header files to the location of tclsh and wish. I suggest > you use the "message(...) command on the components of > TCLTK_POSSIBLE_LIB_PATHS to see what the exact problem is. I'll try to work this in. Thanks for the suggestions and the pointers. I do realize that the whole auto-configuration end of PLplot is a huge and complex puzzle. I worked on the old AC based system for years, and was always getting e-mail from users complaining of this that or the other that didn't work right. So, I (and Maurice too) was only to happy to relinquish that to others. And I don't want to become the grumpy malcontent who is always complaining about the build system, since I lived through years of being on the receiving end of that kind of stuff, and I know only too well how time consuming it is, and what dedication is required to make it work. And PLplot's auto-configuration support does get many many things right. So kudos to all who have worked so hard to get us from where we were in that area, to where we are now. It is for sure an tremendous improvement. But the new system does seem brittle to me. And I hope that somehow we can get to a point where it behaves more resiliently to variation in the underlying system. As for learning cmake, yes I suppose I need to put more effort into that. But that is actually one of my beef's with cmake: It seems to take too much effort to learn, given what it is... a utility for sniffing out the characteristics of a system, and producing platform specific makefiles at the end of the analysis. Everytime I try to debug the cmake system, I find that almost everything I try doesn't work, and if I read and read and read I eventually conclude that what I first tried was just dumb. Etc. Fundamentally, I just can't understand why anyone would invent a new language *and* a new "library" for doing something as basic as what I might call "system sleuthing". Werner already pointed out that shell scripting could work, but that it wouldn't work on Windows. The multi-platform aspect of cmake is one of it's strengths. Acknowledged. But I was ruminating on this today, and I think it's a key point that there are plenty of "universal languages" out there. Okay, maybe zsh isn't an example. While it isn't "unix bound" per se, I'm sure it could work in Cygwin, the point that it isn't a normal component of a Windows system is clear enough. But what about Python? If I was trying to build a system from scratch with the same goals as cmake (as far as I understand that from the reading that I have done about it), there is no way on earth I would've started off by defining a new language. Especially not a quirky, byzantine language. Isn't Python on every platform that cmake is on? Wouldn't it make a lot more sense to have used a "real language", with great data structures, and libraries, and a module system, and all that? I can't help thinking that by the time I figure out how to make cmake do what I want, I could have accomplished the same thing in a fraction of the time if it was written in a modern/popular system programming language (like Python, though there are other languages of other names that could do the job too). What is my point and why am I bothering to express this viewpoint on the list? Mainly that I think most people would find our build system less daunting if it were written in something like Python instead of the cmake-language. If I spend time learning cmake, I only improve my skills with the PLplot build system. Nothing else I use (meaning, develop) uses cmake. But if I spend time learning more about Python, I can apply that to a couple dozen projects I am also involved in besides the PLplot build system. I think the same analysis would apply to many others. Having the PLplot build system written in cmake means many people will never invest the time to become proficient at molding and shaping it. Were the PLplot build system "cmake-like", but written in Python, I bet a lot more people would find it accessible. -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
