[M3devel] Windows issue

[Dirk Muysers]

Both solutions 1. as well as 2. work only from within the shell where vcvars32 was called.
Let's say you use the second solution and open a unix shell (e.g. UWIN's korn shell) the
effect of vcvars32 is not visible from with that shell, and also if you open vim from within
the ms command shell after calling "cmd /k" and then cm3 from within vim, the same thing
happens, the effect of vcvars is strictly limited to the "CMD" environment.
A brute force approach such as copying "link.exe" to cm3/bin doesn't work either because
"link" refers to many (how many?) other files within the VS environment (e.g. mspdb100.dll).

Now, the the interest of calling cm3 from within VIM resides in the fact that it leads one
directly to the faulty lines in your preferred editor, sure, not as elegantly as in a real IDE
such as Visual Studio or Eclipse, but fair enough if you are used to it.
And Microsoft's command shell is a  pain in the backside to say the least.
(it uses a weird file syntax, it can't remember its history between incarnations, it doesn't
allow copy-paste etc etc) One is bound to hate it.

And also, sorry to say so, cm3ide is far from being an elegant development tool, you can
inspect only one file at a time and using VIM from cm3ide brings you back to the above
dilemma.


From: Jay K 
Sent: Friday, October 19, 2012 5:51 PM
To: Tony ; m3devel 
Subject: Re: [M3devel] Windows issue


 > I know there exists vcvars32.bat, but its effect is not permanent.

 
Sure it is. If you use it right. Permance is relative.
There are two easy ways.
 
 
1. start; run; run vcvars32.bat; stay in same cmd and use cm3
 
 
2. somewhere on the start menu is a link that will do #1 -- opens up a cmd that runs vcvars32.bat and sticks around; the command line for the shortcut is roughly cmd /k c:\program files (x86)\visual studio\vcvars32.bat -- that /k means "run and don't exit" as opposed to the Unix-shell-like /c which means "run and exit". (see cmd /? for plenty more decent documentation -- cmd isn't great, but it is better than people realize, and the command line editor and text output performance are a lot better than anything else I've used; the scripting language aspect of it is not good though -- use Python instead...).
 
 
 > It should be invoked somewhere by cm3/bin/config/NT386.common etc.
 
 
Not really. But maybe/kind of/store of. If we could find vcvars32.bat, then we can likely know all that it does and just do it ourselves. Granted, past versions did try to do something like that, but they didn't work well. They hunted around in a few places for C compiler and linker, asked user to confirm, and tried to form up short paths to them. Short paths aren't predictable, aren't necessarily stable across backup/restore (APIs added only as recently as Windows XP to set them), and aren't available on all file systems -- either tools should tolerate spaces, or depend on %PATH%, %LIB%, and %INCLUDE%.
 
 
Perhaps an option to configure where vcvars32.bat is and run it, and then run other stuff, should be considered. Because "it isn't permanant", what one can do is generate a little temporary .cmd file that runs vcvars32.bat, then does whatever you "really" wanted to do, then exists.
 
 
Another thing we can consider is symlinks or hardlinks.
We could create \cm3\bin\cl.exe, \cm3\bin\link.exe that..er..nevermind that..matter of setting %INCLUDE% and %LIB% not dealt with.., but this:
 
 
We could create \cm3\bin\cl.cmd and \cm3\bin\link.cmd that run vcvars32.bat and then cl.exe/link.exe -- they'd be considered user editable to find vcvars.bat.
 
 
On the other hand..I have a LOT of history with wrapper programs and such..might be better to create cl.exe/link.exe or cl.com/link.com that read some input and then run the real cl.exe/link.exe.
I've been through a similar exercise with nmake and I'm happier to have nmake.com than nmake.cmd. ".com" comes before ".exe" in %PATHEXT% so if you run "foo" and there is "foo.com" and "foo.exe", "foo.com" will be run. Whereas ".cmd" is after ".exe" so if you have foo.cmd and foo.exe and run "foo", "foo.exe" will be run.
 
 
The lesson is "users should run foo" and "creative environments" should introduce "foo.com".
 
 
But still, cl.cmd/link.cmd are easier because they would look like this:
call c:\program files\...vcvars32.bat -- user editable line
%~0.exe %* -- foo.cmd => foo.exe, with repeated command line.
 
 
whereas foo.com would have to either replicate vcvars32.bat somehow, or create a wrapper .cmd..
 
 
Thoughts?
Really asis is not bad -- run vcvars32.bat yourself, and then use cm3.
 
 
 - Jay
 


--------------------------------------------------------------------------------
From: hosking at cs.purdue.edu
Date: Fri, 19 Oct 2012 09:56:11 -0400
To: m3devel at elegosoft.com
Subject: [M3devel] Windows issue


I have had a query from a user of CM3 regarding Windows installation.  I am completely at sea answering since I never use Windows.


Here is his question:


I have a problem with the M3 compiler since I have installed Visual Studio 10.
cm3 does not find the Windows linker. I work with vim and have configured the
make macro to call cm3/bin/cm3.exe and the error happens when quake tries to
invoke the MS tools. I know there exists vcvars32.bat, but its effect is not permanent.
It should be invoked somewhere by cm3/bin/config/NT386.common etc.


Can anyone help?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20121020/b26cf4fa/attachment-0002.html>