Hi >> Alas, your patch doesn't work on my machine for three reasons: >> >> 1) I use VCExpress version to build vim. This is VC8, but there is >> no SDK. > > I didn't think the Express version of the compilers supported optimized > code generation. And I am surprised VCExpress comes without nmake. > I don't know either if Express optimizes well -- at least it doesn't issue any warnings about unrecognised compiler options since I applied your patch.
The VCExpress version have an own version of nmake. But it doesn't have an SDK. So I have to install this separately. I thought the best thing is to use a batch file located at %ProgramFiles%\Microsoft Platform SDK\SetEnv.Cmd to set up the environment, but may be I'm wrong. With this batch script first the path of the SDK is searched, and after that the path of the VCExpress tools. So the nmake of SDK is found first. >> ..., but since version 7.0 of the VC toolset there >> exists a environment variable MSVCVer which IMHO should be used >> when it is defined. >> > I don't believe this is the case. For my install of VC8 there is no > MSVCVER variable defined. Could this may be a feature of VCExpress? > It's a feature of the SDK, not of the Visual Tools. MSVCVer is defined by the mentioned batch application SetEnv.Cmd. > So there are now two issues. Non-SDK build environments don't have > MSVCVER variable, while SDK build environments have version numbers that > can be out of synch with the version of Visual C. > Not exactly: The SDK script mentioned above searches for a VC environment. If it finds one, it sets the MSVCVer environment variable appropriate to the C compiler it has found. > It would be nice to keep the makefile handle its environment > automatically without developers having to define variables to > get it to build "out of the box". Perhaps it should first check > for MSVCVER and if not defined fallback on _NMAKE_VER. Thoughts? > This would be fine! Best regards Mathias
