Guys,
I have been searching for information on how to use DEBUGSOURCES to find the
problem I am having in my program, unfortunately there is very little in the
source distribution + web pages and nothing other than find|grep to direct you
to it. May I suggest that the following which is a compilation of knowledge
that I have been able to find be, as Jon A. Christopher suggested (Sept. 99),
placed either into a file called HACKING or appended to BUG-REPORTING, and
then committed to the repository.
From a Lesstif Mailing List thread circa 3 Sep 1999, from Jon A.
Christopher, Steve Kargl,
and Rick Scott. (yes this is 95% cut and paste from those three into one file)
--Begin HACKING-----------------------------------------
HACKING
Lesstif is a complicated system, but not overwhelming. We've
collected some tips on hacking LessTif here for your debugging and hacking
pleasure.
DEBUGSOURCES:
DEBUGSOURCES is an environment variable you can set to get debugging
output on a particular collection of source files. DEBUGSOURCES=all will
give you more information than you ever wanted about what lesstif is
doing internally. You can also set DEBUGSOURCES to a single file, or a
list of files: e.g. DEBUGSOURCES=MainW.c:FileSB.c
If your shell is sh, bash, or ksh, you can for example
set DEBUGSOURCES by
DEBUGSOURCES=MainW.c:FileSB.c
export DEBUGSOURCES
or on one line
DEBUGSOURCES=all ./application -sync
If your shell is csh or tcsh, you can set DEBUGSOURCES by
setenv DEBUGSOURCES "MainW.c:FileSB.c"
For more info on DEBUGSOURCES & DEBUG_FILE look in the source file
lesstif/lib/Xm/DebugUtil.c
DEBUG_FILE:
The amount of diagnostics generated by DEBUGSOURCES can exceed the
line buffering of typical terminal settings. The environmental
variable DEBUG_FILE can be used to direct the output to a file
instead of stdout.
Testing patches:
Lesstif has an extensive test tree under test. Since even the most
seemingly trivial change can often have unexpected consequences, we
recommend running the "testall" script under test before and after
applying a patch, to make sure that you haven't broken anything else with
your fix.
--End HACKING-----------------------------------------
and now to my current question:
why is it that when I run my app as
DEBUGSOURCES=all ./app_gui -sync > lt926run.log8 2>&1
it seems to put all the runtime debug (stuff that occurs after XtAppMainLoop
is called) info after the run of the app, I expected it to be mixed in with my
apps printf lines so I could see where stuff, resizes and redraws, was
happening. And is what is dumped at the end just one dump of the last state
of the app or does it contain the info in a form similar to what I was looking
for just all scrunched together?
Note:
DEBUGSOURCES=all ./app_gui -sync >& lt926run.log7
looks the similar, but I did not get a dump at the end (probably because of ^C
to end).
I would mail someone the dump but it is 25Mb!!!! and I cant even begin to
figure out where the info I am looking for is hidden (the problem I am having
shows up as a visual error on the screen, some of the area is just blanked out
when I switch from one mode to another i.e. unmanage one set of functional
elements and manage others in their place). I will attempt to come up with a
demo prog but I am having a hard time understanding why this is even
happening.
Thanks for any help you can give or suggest.
--
______________________________________________________________________________
Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED]
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you.
-- Vance Petree, Virginia Power
