From: Arjen M. <arj...@wl...> - 2006-09-06 10:58:40
|
Werner Smekal wrote: > Hi Arjen, > > on my cygwin system with cmake from the cygwin repository (not > compiled myself) I don't get errors during the cmake run. plplot > freshly checked out. no changes. > > my command was: > cmake -DBUILD_TEST=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -G "Unix > Makefiles" .. > > I run cmake in a subdirectory of plplot which I create (mkdir > buildcygwin). > That is my set-up too - but I think Alan is right, CMake is missing some information on my machine ... Now to figure out what! > > PS: it fails during make compiling the tk bindings but this is > "normal" I think. I hope we can sort that one out too before long, but it seems that the tk bindings require more from the X11 library on Cygwin than is available. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-09-06 19:20:17
|
On 2006-09-06 13:02-0500 Maurice LeBrun wrote: > Alan W. Irwin writes: > > The tkwin "device" was written specifically for > > the "windows" Tk and was careful to avoid the full-featured API. I am > > not sure of the status of the ntk device. > > I always intended to better familarize myself with these other efforts but > never had the time. Don't know if they even work any more. Maurice, I think you misinterpreted my comment about the ntk device. I was not sure of its status relative to the question of the "Unix" versus "Windows" Tk version. However, just to clarify, both the tkwin device (for the limited tests recommended in examples/tk/README.tkdemos) and the ntk device work fine on Linux both for our ABS and our CBS. But their GUI functionality is quite limited compared with what you have done with plserver and device tk. Also, you continue to refine your work, and there has been no continuing development for either the ntk or tkwin devices. > > > My Tk information is really dated and/or may be wrong in the first place. > > For example, there must now be some X11 workalike (or maybe even the real > > thing) available on windows since libqt4 (and KDE4 when it is done) work on > > windows. > > > > Maurice, just to set the record straight, could you comment about the > > current status of Tk and X11 on windows? > > No idea, sorry. Too bad. I guess our windows users will just have to figure it out from the results of experiments that they do. An alternative explanation of the problems they are having with PLD_tk ON is there is some dynamic linking issue that needs to be sorted out with our CBS for that case. They should also try the static library case to see if the plserver and -dev tk results are any better. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2006-09-08 15:32:58
|
On 2006-09-08 08:41+0200 Arjen Markus wrote: > I found the solution: > > CMake was picking up cache files from the source directory. [...] Yes, it will always do that if the source tree has been contaminated by an in-source build. See FAQ item http://www.cmake.org/Wiki/CMake_FAQ#I_run_an_out-of-source_build_but_CMake_generates_in-source_anyway._Why.3F > So, the general advice is: _Never build in the source directory_, always > use a different directory (even if you think you will only need one > platform). Good advice indeed. For our ABS, it took significant effort to get the out-of-source tree build to work at all so I never quite trusted it and formed the habit of in-source-tree builds. However, now that cmake has reminded me to get rid of that (bad) habit, it turns out I really like out-of-source-tree builds. No more worries about a dirty source tree with stale build files scattered around, multiple build trees can be used for different sets of options (or even different platforms in Arjen's case), and "rm -rf" on one of those build trees gives you an absolutely clean start. Perfect! 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2006-09-12 17:08:15
|
On 2006-09-12 09:55+0200 Werner Smekal wrote: > Hi, > >> Arjen and Werner, for an interesting experiment on Cygwin you may want to >> try PLD_tk OFF (which should still leave ENABLE_tk, PLD_ntk, and PLD_tkwin >> ON). Under these circumstances, does tkwin work? > > tkwin compiles but there are still problems with tcl/tk bindings. I tried to > turn them off (ENABLE_tcl=OFF) than tk bindings produce even more errors - > shouldn't tk bindings also be turned off, if tcl bindings are not available? Yes. However, at minimum you must remove the cache file, CMakeCache.txt, if you want to try different options, but I suggest for now until we gain more experience with cmake, you just remove the whole build tree just to be absolutely sure you have a clean start. If you make a clean start, then ENABLE_tcl=OFF will turn off everything related to either Tcl or Tk. You should check that that works, but once that is confirmed it is fundamentally an uninteresting experiment. For a more interesting experiment, I suggest you try PLD_tk OFF while leaving ENABLE_tcl (which I didn't mention before), ENABLE_tk, PLD_ntk, and PLD_tkwin ON. If you use a clean start, I don't think you should have any problems with that combination of options. N.B. the PLD options are normally related to the device drivers (i.e., what goes into the core plplot library when dynamic devices are disabled or how many plug-ins [dynamic devices] are built when dynamic devices are enabled), while the ENABLE options (that we have mentioned in this case) are normally related to what goes into the plplottcltk library. > > ntk is also depended on ENABLE_TK though from the tk.cmake it's not obvious > why? device ntk needs certain Tk-related compiled objects in the plplottcltk library which only ENABLE_TK can supply. > > It seems that if tk is enabled the bindings are also compiled, though for ntk > it doesn't seem to be necessary. There should be another option > ENABLE_tcl_bindings and ENABLE_tk_bindings which are off if ENABLE_tcl/tk is > off and can be switched on/off if ENABLE_tcl/tk is on. tk and tkwin driver > also depend on bindings, but not ntk (so it seems). Alan, would this make > sense? No. I think some of your impressions have been formed by not making a clean start each time you change options. It's also possible you need to do cvs update to synchronize with the latest CVS version. See also the explanation above as to the meanings of the various Tcl/Tk PLD and ENABLE flags. If you still don't get good results with latest CVS and a clean start, please let me know the exact combination of cmake options that you used and all output from cmake and your build. I believe I have tested all combinations of the Tcl/Tk related flags on Linux, but it's possible there are still some problems with the option logic. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2006-09-12 17:32:50
|
On 2006-09-12 12:09+0200 Arjen Markus wrote: > It turns out that the functions Tcl_GetOpenFile() and others are > used for very very specific purposes - things that have to be done > using low-level UNIX system functions. > > I have not studied the relevant code, but it appears to me that > we could reprogram this part of the Tk bindings in PLplot, > using "channels" rather than this low-level stuff. Yes, some windows replacement for these three 'Unix only' functions (Tcl_CreateFileHandler, Tcl_DeleteFileHandler, and Tcl_GetOpenFile) would probably be a better idea then what occurs in bindings/tk-x-plat/plplotter.c (which bypasses use of these functions in the windows case). 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2006-09-05 20:45:24
|
On 2006-09-05 21:29+0200 Arjen Markus wrote: >> On 2006-09-05 11:01-0700 Alan W. Irwin wrote: >> > >> That still leaves one obvious problem with pltclgen.tcl. It generates >> many lines of the following warning message: >> >> Unrecognized argtype : <getargs> >> >> Apparently, there is no harm done (ctest passes all tests including >> tcl), but Arjen, could you fix this please just to keep things clean? >> > > Done, I had forgotten a "continue" statement. Thanks, Arjen, for your work on this issue and also your better fix for the separate build-tree issue. The result passes all my tests on Linux. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |