On 2008-08-13 15:19-0600 Orion Poplawski wrote: > Andrew Ross wrote: >> In principal I like the idea of being able to see the examples as they >> are exectuted. I wonder whether the whole command line is necessary >> though. Perhaps just echoing the example name would suffice and would >> prevent too much unnecessary clutter in the output? For testing purposes >> this is what is required. For a given test you know what the driver is >> and what the output files will be. I find looking through >> Testing/Temporary/LastTest.log useful and all this extra information >> could make it more difficult to find useful error messages. > > Perhaps another --debug option? What I find hard is when a test is > segfaulting finding the command I need to execute to reproduce it directly so > that I can run it under gdb. I agree for "normal" operation the command is > not necessary and may be harmful.
Sorry, Orion, I missed your comment before I made the changes. There are two possible use cases here. Just as a general principle, I think debugging in the install tree is just a whole lot cleaner than in the build tree so I highly recommend it. Doing gdb sessions in the install tree is quite simple because no environment variables have to be set, and you know where everything is. For that case, your suggested --debug option for plplot-test.sh only has limited usefulness for those who are already familiar with running examples in the install tree. However, I suspect you were considering just the build-tree case when you made your proposal, and see below for the limitations in that case. Doing gdb sessions in the build tree is pretty tricky because of all the setup (e.g., setting environment variables) you have to do first. So I don't recommend it except for rare emergencies where you get errors in the build tree but not the install tree. Furthermore, ctest doesn't have a facility to pass options on to plplot-test.sh so we have to choose the plplot-test.sh options for the build tree at cmake time which would not be very convenient for you. So for the above reasons I am not completely keen on your idea. However, if you still are keen after considering what I have said above, then please send me a patch with the implementation (not only the changes to plplot-test.sh.in, but the extra logic required in the various test_*.sh.in files). Assuming the patch looks okay, I can deal with the cmake details so that there is a cmake option such that ctest runs plplot-test.sh with both the --verbose and --debug options. 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
