Topic: Launching compiler from VPW (1 of 14), Read 342 times
Conf: Compiler support
From: Ted Green
Date: Tuesday, February 16, 1999 08:54 AM

Here are some tips on how to debug compiler support problems:

1. Make sure your compile.cnf file lists the correct compiler line. You must either include the full pathname to the compiler's
executable, e.g. "cl.exe", or it must be in the PATH. The compile.cnf file must be in the VEDIT Home directory, e.g. "c:\vedit".

2. Make sure you can run the compiler from the {MISC, Run program} menu function. If it doesn't work from here, try running it from a DOS prompt outside of VEDIT.

3. Make sure you have a .VCS file which matches the compiler's executable name, e.g. "cl.vcs". This file must be in the ..\compile subdirectory, e.g. "c:\vedit\compile". Make sure that the .vcs file is a recent one; if you have a custom .vcs file from VEDIT 4.x, you must modify it to work with VEDIT 5.x.

4. Read over the on-line help topic "Compiler support" again.

 


Topic: Launching compiler from VPW (2 of 14), Read 354 times
Conf: Compiler support
From: Deleted User
Date: Tuesday, February 16, 1999 10:18 AM

I found the problem.

My working directory was defined in the Windows 95 long format, and contained spaces; i.e,

"c:\project\version 3.1\main.c"

When I launched the compiler from VEDIT, a macro, vcs.tmp, was created which did a CD\ called the cl.exe compiler. The full path for -proj was expanded in vcs.tmp and it was not in quotes. Even if it had been in quotes, the Microsoft C version 6.0 (DOS) command line parser was unable to handle the Win95 path format.

The solution is to rename the directory and leave out the spaces. Alternatively, perhaps there's a way to tell compiler support to not expand the filename to the full path.

The problem of compiler paths and set environment was solved by creating a batch file, CL.BAT, to set the path and environment variables and then call CL.EXE.

 


Topic: Launching compiler from VPW (3 of 14), Read 239 times
Conf: Compiler support
From: Deleted User
Date: Wednesday, March 22, 2000 12:20 PM

I have had similar problems, and noted an odd behavior under Windows NT:

Open up a Java file (in a dir with a long file name like "jdk.1.2.2") by double clicking on it. VEDIT opens up using the long file name.

Start Java compiler support and try to compile. You get the same vcs error message (kinda cryptic!)

But note that your file is now in window 2! If you move to window 1, you see the file again, this time with the truncated file name. This one you can compile successfully.

Not sure of why the behavior exists (and certainly wish it would just compile normally), but really glad there's a workaround.

Jim Stanley
Jacobs Engineering

 


Topic: Launching compiler from VPW (4 of 14), Read 122 times
Conf: Compiler support
From: Pauli Lindgren
Date: Monday, June 17, 2002 07:20 AM

Has anybody been able to get the compiler support work with Windows version of Vedit?

I have been trying it since the first Vedit Windows version V5.0 was published, but with no success. I did use the compiler support with DOS version for many years, and it worked fine, but Windows version simply refuses to work.

I have been using NT4 and Windows 2000, with IAR and Tasking C cross compilers.

If I try "Compile", I get error message "No vcs.tmp error/output file created or cannot run compiler/tool".

If I try "Make", the computer does something for a while and then stops and nothing else happens. If I then try "Examine errors", I get error message "No errors available (no vcs.tmp file)".

I have made the necessary .vcs file.
I have edited the compile.cnf to use this compiler.
The PATH and all necessary environment variables have been set.
I have deliberately made some errors in the program to test the
compiler support.

I noticed that when the compiler is run, the compiler command is displayed at the bottom of the screen. At the end of this line, there is text " > vcs.tmp". However, I have changed that in my cc88.vdm into ">& vcs.tmp", in order to reroute stderr to a file, too. I wonder why my change does not have effect?

I made a BAT file ccc.bat that runs the compiler and reroutes the output to a file with ">& vcs.tmp". When I run this bat file from DOS command prompt, the compiler runs ok and vcs.tmp file is created. When I run it from Vedit with "Misc" -> "Save and run programs", the DOS window opens briefly and closes, but no vcs.tmp file is created.

 


Topic: Re: Launching compiler from VPW (5 of 14), Read 125 times
Conf: Compiler support
From: Christian Ziemski
Date: Monday, June 17, 2002 12:30 PM

Pauli,

please take a look at the JAVA.VCS, especially at those line:

//
// Run compiler
//
:COMPILE:
if (Is_WinNT) {
Reg_Set(98," > vcs.tmp 2>&1") //Reroute stdout and stderr to vcs.tmp
} else {
Reg_Set(98," > vcs.tmp") //Reroute stdout to vcs.tmp
}
Call(103,"MAKE-BAT") // Create VCS-TMP.BAT file. @103 is C-INIT.VDM
System("|@(96)\vcs-tmp.bat",DOS+NOMSG+SIMPLE)
Return


Maybe the rerouting isn't correct in your .VCS file and a modification
like above could help?


Christian

 


Topic: Re: Launching compiler from VPW (6 of 14), Read 124 times
Conf: Compiler support
From: Pauli Lindgren
Date: Friday, June 28, 2002 04:13 AM

>:COMPILE:
>if (Is_WinNT) {
> Reg_Set(98," > vcs.tmp 2>&1") //Reroute stdout and stderr to vcs.tmp
>} else {
> Reg_Set(98," > vcs.tmp") //Reroute stdout to vcs.tmp
>}
...
>Maybe the rerouting isn't
>correct in your .VCS file and
>a modification
>like above could help?
>
>
>Christian

The rerouting I used was the only method I found from Windows Help. (Windows 2000 help has even less information on the subject than NT4 did.) And it works in .bat file, but not from Vedit.

(My .vcs file was based on cl.vcs, which does not have the code to detect WinNT.)

Anyway, I made the change to the .vcs file. Now the "Compile" command in Tools menu worked, but "Make" did not.

I then edited the file C-MAKE.VDM and made the same changes in it. Now the "Make" command works, too.

There is still a small problem. If there are no errors when make is run, the compiler support does not display anything when finished. (I think there should be some message, e.g. "No errors", perhaps in the status line.) If you then select "Examine errors", an error message "No errors available (No vcs.tmp file)..." is displayed. (The "compile" command, on the other hand, does display the compiler output in a window.)

Ted, maybe these changes will be done in the supplied compiler support files in future releases?


-- Pauli

 


Topic: Re: Launching compiler from VPW (7 of 14), Read 133 times
Conf: Compiler support
From: Christian Ziemski
Date: Friday, June 28, 2002 04:52 PM

>The rerouting I used was the only method I found from Windows Help.
>(Windows 2000 help has even less information on the subject than NT4 =did.)

Pauli:

I'll try to give you some explanations.

One of the problems is that the redirection(rerouting) is NOT
implemented all the same way in the different Windows versions.
And there are different command prompts too ...

Windows 95 and 98 are using COMMAND.COM as DOS-prompt.
Windows NT and 2000 have CMD.EXE (or COMMAND.COM for some backwards
compatibility)

The older COMMAND.COM only knows about the StdOut redirection.
The newer CMD.EXE knows the StdOut plus the StrErr redirection.
(StdOut refers to "channel 1" and StdErr refers to "channel 2".)

And the CMD.EXE can be modified by switching the "command extensions"
on or off: in NT "off" is default, in Win2000 "on" is default.
Maybe that's another reason for differences...


That means:
All Windows' DOS prompts (and this way batch files started with the
same command processor) which know only the StdOut redirection will
write StdOut AND StdErr from compilers etc. into the redirection file
when a simple ">outfile" is used.

But using the same script or command in enhanced DOS prompts (which
know both types of redirection) will write only the StdOut to that
outfile. The error messages from compilers (usually written to StdErr)
won't be redirected this way. To do this you have to use a "2>errfile"
to redirect that to an extra file or "2>&1" to write StdErr to StdOut
too (and that is redirected to a file).

You see: The VEDIT macros have to handle very different cases. And
that's not always trivial.

Hopefully I was able to bring some lights onto that.


>There is still a small problem. If there are no errors when make is run,=
>the compiler support does not display anything when finished.
>[...]

I'll have a look at this (maybe tomorrow).


Christian

 


Topic: Re: Launching compiler from VPW (8 of 14), Read 135 times
Conf: Compiler support
From: Christian Ziemski
Date: Monday, July 01, 2002 05:17 PM

>>There is still a small problem. If there are no errors when make is =run,=
>>the compiler support does not display anything when finished.
>>[...]
>
>I'll have a look at this (maybe tomorrow).

I don't have any compiler with make utility here to test that.

And so I have to say:
Sorry, I don't have the time now to try to evaluate that just via
macro code. Maybe sometime later ...

Christian

 


Topic: Re: Launching compiler from VPW (9 of 14), Read 129 times
Conf: Compiler support
From: Pauli Lindgren
Date: Wednesday, July 03, 2002 09:44 AM

>The older COMMAND.COM only knows about the StdOut redirection.
>The newer CMD.EXE knows the StdOut plus the StrErr redirection.

I know that. That is why I used the command to redirect stderr, too. However, since I could not find the necessary information from Windows 2000 help, I used the help of 4NT. I now realize that the syntax I used first was the enhanced syntax of 4NT, and CMD.EXE does not understand it (it is not said very clearly in the help). That is why it worked from bat file but not from within Vedit.

Anyway, it works now. Now we just need to change all the compiler support files to handle NT/2000 (and XP?).

>
>>There is still a small problem. If there are no errors when make is run,=
>>the compiler support does not display anything when finished.
>>[...]
>
>I'll have a look at this
>(maybe tomorrow).

Another problem is that the errors from the linker are not displayed anywhere.

Yet another problem is the "current directory". The compiler support help keeps talking about "current directory", but in Windows, you can never know what directory is the current directory. This means that you never know which compile.vco, if any, is used. And, of course, compiler and make do not work correctly if you are not in the directory the compiler or make expects.

To solve this problem, the compiler support code should perhaps be modified so that the current directory is set to be the directory of the currently open source file. This is the method I have used in my RCS support macros, as well as in my WildSearch macro.


-- Pauli

 


Topic: Re: Launching compiler from VPW (10 of 14), Read 136 times
Conf: Compiler support
From: Christian Ziemski
Date: Wednesday, July 03, 2002 04:43 PM

Pauli:

>>The older COMMAND.COM only knows about the StdOut redirection.
>>The newer CMD.EXE knows the StdOut plus the StrErr redirection.
>
>I know that.

Ooops. Sorry. But maybe other readers learned something new...

>...
>I now realize that the syntax I used first was the enhanced syntax of 4NT,
>and CMD.EXE does not understand it.

Aha. I don't know 4NT but I assume it's something like 4DOS (which I don't use too).
That explains your syntax, I first read as typos...


>Anyway, it works now. Now we just need to change all the compiler support
>files to handle NT/2000 (and XP?).

That's what I thought too in the first moment.
But Ted answered that the supplied VCS files are working o.k. and he doesn't want to break that.
He added the new redirection to the SAMPLE.VCS in the new 6.03.2.
So every user can have a look at it. (Maybe Ted will jump in here?)


Christian

 


Topic: Re: Launching compiler from VPW (11 of 14), Read 133 times
Conf: Compiler support
From: Ted Green
Date: Friday, July 05, 2002 11:17 AM

At 04:43 PM 7/3/2002, you wrote:

>But Ted answered that the supplied VCS files are working o.k. and he doesn't want to break that.
>He added the new redirection to the SAMPLE.VCS in the new 6.03.2.
>So every user can have a look at it. (Maybe Ted will jump in here?)

I will be happy to add the StdErr redirection code for any compiler's .VCS file which uses StdErr. I think that most compilers just use StdOut.

Ted.

 


Topic: Re: Launching compiler from VPW (12 of 14), Read 35 times
Conf: Compiler support
From: Peter Rejto
Date: Thursday, January 01, 2009 08:06 AM

On 7/3/2002 4:43:26 PM, Christian Ziemski wrote:
>Pauli:
>
>>>The older COMMAND.COM only knows about the StdOut redirection.
>>>The newer CMD.EXE knows the StdOut plus the StrErr redirection.
>>

Christian,

I just did some experiments with CMD.EXE and got plenty of error messages. Of course, I would like to save these error messages to a file.

My specific question is this: Could I use your comment,

>The newer CMD.EXE knows the StdOut plus the StrErr >redirection.

to do that? If so, I would appreciate getting additional information.

-peter.

 


Topic: Re: Launching compiler from VPW (13 of 14), Read 39 times
Conf: Compiler support
From: Christian Ziemski
Date: Thursday, January 01, 2009 04:08 PM

On 01.01.2009 14:20 in vtech-compile Peter Rejto wrote:
>
> I just did some experiments with CMD.EXE and got plenty of error
> messages. Of course, I would like to save these error messages to a
> file.
>
> My specific question is this: Could I use your comment,
>
>> The newer CMD.EXE knows the StdOut plus the StrErr >redirection.
>
> to do that?

Isn't the description in the message above in this thread (as of "Friday, June 28, 2002 04:52 PM") detailed enough?

In short:

some_program.exe > stdout.txt
some_program.exe 2> stderr.txt
some_program.exe > stdout+err.txt 2>&1


Christian

 


Topic: Re: Launching compiler from VPW (14 of 14), Read 32 times
Conf: Compiler support
From: Peter Rejto
Date: Thursday, January 01, 2009 05:22 PM

On 1/1/2009 4:08:14 PM, Christian Ziemski wrote:

>In short:
>
>some_program.exe > stdout.txt
>some_program.exe 2> stderr.txt
>some_program.exe > stdout+err.txt 2>&1


Thanks Christian,

This works like a charm for me. The previous version was a bit too condensed for me.

Thanks as always,

peter