Initial Questions from Win32 User

Initial Questions from Win32 User

[Stan Mitchell]

Hello All

Thank you for making SN available as open source. 
I've been using it since version 4.2. Now that I can 
customize it more to my needs, it may get a lot more 
"air time" on my development machine.

So far, I've been able to build the distribution using 
cygwin and VC++6. Next, I'm looking at starting some 
customizations and I have some related questions.

It would seem that ../snav/share/gui/*.tcl are the core
application source files. Are these executed as script
files or are they byte-compiled during the build & install?

Is there some facility for debug tracing, such as an output 
widget or console to which debug print statements can be 
directed?

Lastly, there is one serious problem (to me at least) with 
the redirection of output from compiler tools. Our build
process uses some "front-ends" to make. The output from
the front-end tool is displayed in the output browser
but the output from make and the compilers appears in a
separate Win32 console. As soon as the build completes,
the console is removed, and so is the output, since it is
not redirected to the browser. This makes it impossible
to navigate to source lines where compile errors have
occurred. Is this something that can be fixed in multimake.tcl
or is it a problem with tcl's 'exec' command?

Thanks,
Stan Mitchell
SourceQuest, Inc.

Re: Initial Questions from Win32 User

[Mo DeJong]

On Fri, 18 Aug 2000, Stan Mitchell wrote:

> Hello All

Hello Stan.

> Thank you for making SN available as open source. 
> I've been using it since version 4.2. Now that I can 
> customize it more to my needs, it may get a lot more 
> "air time" on my development machine.
> 
> So far, I've been able to build the distribution using 
> cygwin and VC++6. Next, I'm looking at starting some 
> customizations and I have some related questions.
> 
> It would seem that ../snav/share/gui/*.tcl are the core
> application source files. Are these executed as script
> files or are they byte-compiled during the build & install?

Tcl has a built in byte code compiler, the .tcl source
files get compiled as needed at runtime. The sources
are all that you need to install.
 
> Is there some facility for debug tracing, such as an output 
> widget or console to which debug print statements can be 
> directed?

Yes, start SN like this to print debug info:

./snavigator --debug 9

> Lastly, there is one serious problem (to me at least) with 
> the redirection of output from compiler tools. Our build
> process uses some "front-ends" to make. The output from
> the front-end tool is displayed in the output browser
> but the output from make and the compilers appears in a
> separate Win32 console. As soon as the build completes,
> the console is removed, and so is the output, since it is
> not redirected to the browser. This makes it impossible
> to navigate to source lines where compile errors have
> occurred. Is this something that can be fixed in multimake.tcl
> or is it a problem with tcl's 'exec' command?

It sounds like a problem with your front end. You need to
exec the process that is going to write compiler output
to stdout.

Mo DeJong
Red Hat Inc

Re: Initial Questions from Win32 User

[Ian Roxborough]

Mo DeJong wrote:
> > Is there some facility for debug tracing, such as an output
> > widget or console to which debug print statements can be
> > directed?
> 
> Yes, start SN like this to print debug info:
> 
> ./snavigator --debug 9

A quick note for Windows users:  You can turn debugging
on in Windows by set the enviroment variable SN_DEBUG to
the debug level you want to use.  I.E.:

"set SN_DEBUG = 9" is the same as "./snavigator --debug 9"

(As far as I remember, flags are pretty much ignored in the
Windows version.)

Ian.

Re: Initial Questions from Win32 User

[Ian Roxborough]

Ian Roxborough wrote:
> A quick note for Windows users:  You can turn debugging
> on in Windows by set the enviroment variable SN_DEBUG to
> the debug level you want to use.  I.E.:
> 
> "set SN_DEBUG = 9" is the same as "./snavigator --debug 9"
> 
> (As far as I remember, flags are pretty much ignored in the
> Windows version.)

Another note: All the debug info is stored in a file in a
directory determined by the contents of the TMP (or TEMP)
environment variable (no console output).

Ian.

RE: Initial Questions from Win32 User

[Stan Mitchell]

Hi Ian

Yes, I found the --debug option was greeted with an error message box
on Win32. The SN_DEBUG environment variable works ok though, and the 
log files are generated as %TMP%/zznavigNN.log.

I've written a small extension DLL that adds "dbgwin print" and
"dbgwin break" Tcl commands. These send output strings to, or 
cause a break into a Win32 debugger. A bit primitive, bit it will
do.

Thanks
-Stan 

> -----Original Message-----
> From: sourcenav-owner@sources.redhat.com
> [ mailto:sourcenav-owner@sources.redhat.com]On Behalf Of Ian Roxborough
> Sent: Saturday, August 19, 2000 11:32 PM
> To: Source Navigator Mail-List
> Subject: Re: Initial Questions from Win32 User
> 
> 
> Ian Roxborough wrote:
> > A quick note for Windows users:  You can turn debugging
> > on in Windows by set the enviroment variable SN_DEBUG to
> > the debug level you want to use.  I.E.:
> > 
> > "set SN_DEBUG = 9" is the same as "./snavigator --debug 9"
> > 
> > (As far as I remember, flags are pretty much ignored in the
> > Windows version.)
> 
> Another note: All the debug info is stored in a file in a
> directory determined by the contents of the TMP (or TEMP)
> environment variable (no console output).
> 
> Ian.
> 

Re: Initial Questions from Win32 User

[Syd Polk]

At 06:44 PM 8/18/00 -0700, Stan Mitchell wrote:
>Hello All
>
>Thank you for making SN available as open source.
>I've been using it since version 4.2. Now that I can
>customize it more to my needs, it may get a lot more
>"air time" on my development machine.
>
>So far, I've been able to build the distribution using
>cygwin and VC++6. Next, I'm looking at starting some
>customizations and I have some related questions.
>
>It would seem that ../snav/share/gui/*.tcl are the core
>application source files. Are these executed as script
>files or are they byte-compiled during the build & install?

They are executed as script files, but tcl itself converts the scripts to 
byte-codes and remembers them later. They are only parsed as scripts once.


>Is there some facility for debug tracing, such as an output
>widget or console to which debug print statements can be
>directed?

Well, if you start from a DOS prompt with the environment variable SN_DEBUG 
set to 1, 2, etc., you will see lots of debugging output.

>Lastly, there is one serious problem (to me at least) with
>the redirection of output from compiler tools. Our build
>process uses some "front-ends" to make. The output from
>the front-end tool is displayed in the output browser
>but the output from make and the compilers appears in a
>separate Win32 console. As soon as the build completes,
>the console is removed, and so is the output, since it is
>not redirected to the browser. This makes it impossible
>to navigate to source lines where compile errors have
>occurred. Is this something that can be fixed in multimake.tcl
>or is it a problem with tcl's 'exec' command?
>
>Thanks,
>Stan Mitchell
>SourceQuest, Inc.

I would need more detail on what you are trying to do.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

RE: Initial Questions from Win32 User

[Stan Mitchell]

Hi, Syd

> >Lastly, there is one serious problem (to me at least) with
> >the redirection of output from compiler tools.... 
> 
> I would need more detail on what you are trying to do.

I have a front-end console tool called premake.exe. It processes its
command line and then invokes NMAKE.EXE using the 'C' system() function.
If I enter "premake.exe -?", premake will output two lines of info and
then invoke 'system("nmake.exe -?")', which will display nmake's command
line usage help. 

When I do this from VC6, Ntemacs, SlickEdit, CodeWright, TextPad, etc.,
the output from both premake and nmake is captured together. 

When I do this from SN, only the output from premake is captured. 
Corresponding to the system() call I see a new console window opened 
and the output from that command written there.

I'm giving you details on premake because I know how it is implemented.
I have also seen this problem with BUILD.EXE, a front-end to NMAKE
provided by MS in its Device Driver Kits. Another user reported a similar
problem with a particular 'C' compiler, earlier in this thread. He kindly
forwarded me a wrapper written in Perl which provided a workaround in his
case.

My operating system is Win2k.

-Stan

RE: Initial Questions from Win32 User

[Syd Polk]

I really do not know how to fix your problem. The entire system of console 
windows on Windows is severe voodoo. The only thing I can really suggest is 
to change the invocation of premake.exe to "command premake.exe -?"; i.e., 
launch your utility in a console window.

At 05:36 PM 8/21/00 -0700, Stan Mitchell wrote:
>Hi, Syd
>
> > >Lastly, there is one serious problem (to me at least) with
> > >the redirection of output from compiler tools....
> >
> > I would need more detail on what you are trying to do.
>
>I have a front-end console tool called premake.exe. It processes its
>command line and then invokes NMAKE.EXE using the 'C' system() function.
>If I enter "premake.exe -?", premake will output two lines of info and
>then invoke 'system("nmake.exe -?")', which will display nmake's command
>line usage help.
>
>When I do this from VC6, Ntemacs, SlickEdit, CodeWright, TextPad, etc.,
>the output from both premake and nmake is captured together.
>
>When I do this from SN, only the output from premake is captured.
>Corresponding to the system() call I see a new console window opened
>and the output from that command written there.
>
>I'm giving you details on premake because I know how it is implemented.
>I have also seen this problem with BUILD.EXE, a front-end to NMAKE
>provided by MS in its Device Driver Kits. Another user reported a similar
>problem with a particular 'C' compiler, earlier in this thread. He kindly
>forwarded me a wrapper written in Perl which provided a workaround in his
>case.
>
>My operating system is Win2k.
>
>-Stan

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Capturing Build Output on Win32

[Stan Mitchell]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

>
> I really do not know how to fix your problem. The entire system of console
> windows on Windows is severe voodoo. The only thing I can really suggest
is
> to change the invocation of premake.exe to "command premake.exe -?"; i.e.,
> launch your utility in a console window.
>

Yes, dealing with Win32 console windows is sometimes daunting.
I've had some luck at coming up with a solution for Win2k/WinNT.
Instead of directly spawning a build tool, I launch an intermediate
process, which I've tentatively named sncapture.exe. Using the example
I gave earlier, the Build dialog would have this command line:

     ../snav/bin/sncapture.exe c:/bin/premake.exe -?

sncapture spawns premake.exe using the inherited handles for
stdin/stderr/stdout
and it explicitly hides the new console window. It then does a
WaitForMultipleObjects on the process handle for premake.exe.
Using this approach all stderr and stdout goes into the browser window.
This is a general solution, it works equally well with other front-end
programs.

As it stands, this is a ~300 line applet, that can be used independently.
It would be more useful if it was integrated with SN, for example, it
could respond to the "Stop" button on the build dialog or it might be
prepended to build command lines if a check-box is checked.

Do you think this is something that might be useful as part of the
SN distribution? If so, I'm willing to do some more work on it.

-Stan

[-- Attachment #2: sncapture.zip --]
[-- Type: application/zip, Size: 42812 bytes --]

Re: Capturing Build Output on Win32

[Syd Polk]

At 07:04 AM 8/23/00 -0700, Stan Mitchell wrote:
> >
> > I really do not know how to fix your problem. The entire system of console
> > windows on Windows is severe voodoo. The only thing I can really suggest
>is
> > to change the invocation of premake.exe to "command premake.exe -?"; i.e.,
> > launch your utility in a console window.
> >
>
>Yes, dealing with Win32 console windows is sometimes daunting.
>I've had some luck at coming up with a solution for Win2k/WinNT.
>Instead of directly spawning a build tool, I launch an intermediate
>process, which I've tentatively named sncapture.exe. Using the example
>I gave earlier, the Build dialog would have this command line:
>
>      ../snav/bin/sncapture.exe c:/bin/premake.exe -?
>
>sncapture spawns premake.exe using the inherited handles for
>stdin/stderr/stdout
>and it explicitly hides the new console window. It then does a
>WaitForMultipleObjects on the process handle for premake.exe.
>Using this approach all stderr and stdout goes into the browser window.
>This is a general solution, it works equally well with other front-end
>programs.
>
>As it stands, this is a ~300 line applet, that can be used independently.
>It would be more useful if it was integrated with SN, for example, it
>could respond to the "Stop" button on the build dialog or it might be
>prepended to build command lines if a check-box is checked.
>
>Do you think this is something that might be useful as part of the
>SN distribution? If so, I'm willing to do some more work on it.

By all means, we would love to have something like this.

>-Stan

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: Capturing Build Output on Win32

[Thomas Heller]

Stan wrote:
> 
> Yes, dealing with Win32 console windows is sometimes daunting.
> I've had some luck at coming up with a solution for Win2k/WinNT.
> Instead of directly spawning a build tool, I launch an intermediate
> process, which I've tentatively named sncapture.exe. Using the example
> I gave earlier, the Build dialog would have this command line:
> 
>      ../snav/bin/sncapture.exe c:/bin/premake.exe -?
> 
> sncapture spawns premake.exe using the inherited handles for
> stdin/stderr/stdout
> and it explicitly hides the new console window. It then does a
> WaitForMultipleObjects on the process handle for premake.exe.
> Using this approach all stderr and stdout goes into the browser window.
> This is a general solution, it works equally well with other front-end
> programs.
> 
IMHO it would be usefull to allow your sncapture program to setup/extend
an environment for the spawned process. This would allow to use
VC6 on one project, Borland in another and so on.
The enviroment could come from an ini-file, given as (optional)
argument.
What do you think?

Thomas

RE: Capturing Build Output on Win32

[Stan Mitchell]

Hi Thomas,

Setting up and extending the environment of a spawned process 
is something that I have found to be very useful too. I wrote 
a separate tool (premake.exe) that does what you describe. It
takes a "config" file that defines an environment for a particular
target. Custom targets can be named (vc6, vc5, etc.) and a
specific environment loaded for them by referencing a section of
the config file.

I worked on preMake in '99 but haven't done much with it recently.
Sources are available at www.sourcequest.com\software.html. I
believe it is now "hardcoded" to work only with nmake.exe but it 
could be modified to support other make programs too. 

If there is interest in premake, I could put together some 
documentation, and add a binary only download.

-Stan 

> -----Original Message-----
> From: Thomas Heller [ mailto:thomas.heller@ion-tof.com ]
> Sent: Monday, August 28, 2000 12:50 AM
> To: Stan Mitchell; Reinhard. Griech@Pcm. Endress. Com; Source Navigator
> Mail-List; Syd Polk
> Subject: Re: Capturing Build Output on Win32
> 
> IMHO it would be usefull to allow your sncapture program to setup/extend
> an environment for the spawned process. This would allow to use
> VC6 on one project, Borland in another and so on.
> The enviroment could come from an ini-file, given as (optional)
> argument.
> What do you think?
> 
> Thomas

Re: Capturing Build Output on Win32

[Mo DeJong]

On Mon, 28 Aug 2000, Thomas Heller wrote:

> Stan wrote:
> > 
> > Yes, dealing with Win32 console windows is sometimes daunting.
> > I've had some luck at coming up with a solution for Win2k/WinNT.
> > Instead of directly spawning a build tool, I launch an intermediate
> > process, which I've tentatively named sncapture.exe. Using the example
> > I gave earlier, the Build dialog would have this command line:
> > 
> >      ../snav/bin/sncapture.exe c:/bin/premake.exe -?
> > 
> > sncapture spawns premake.exe using the inherited handles for
> > stdin/stderr/stdout
> > and it explicitly hides the new console window. It then does a
> > WaitForMultipleObjects on the process handle for premake.exe.
> > Using this approach all stderr and stdout goes into the browser window.
> > This is a general solution, it works equally well with other front-end
> > programs.
> > 
> IMHO it would be usefull to allow your sncapture program to setup/extend
> an environment for the spawned process. This would allow to use
> VC6 on one project, Borland in another and so on.
> The enviroment could come from an ini-file, given as (optional)
> argument.
> What do you think?
> 
> Thomas

You can already set a per build target toolchain. You need to
actually create the toolchain spec, but it is not hard
(see online docs for the details).

Mo DeJong
Red Hat Inc