views:

6116

answers:

6

Visual Studio 2003 and 2005 (and perhaps 2008 for all I know) require the command line user to run in the 'Visual Studio Command Prompt'. When starting this command prompt it sets various environment variables that the C++ compiler, cl, uses when compiling.

This is not always desirable. If, for example, I want to run 'cl' from within Ant, I'd like to avoid having to run Ant from within the 'Visual Studio Command Prompt'. Running vcvars32.bat isn't an option as the environment set by vcvars32.bat would be lost by the time cl was run (if running from within Ant).

Is there an easy way to run cl without having to run from within the Visual Studio command prompt?

+2  A: 

You can simply run the batch file which sets the variables yourself. In VS08 it's located at:-

C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat
kronoz
+6  A: 

The compilers can be used from command line (or makefiles) just like any other compilers. The main things you need to take care of are the INCLUDE and LIB environment variables, and PATH. If you're running from cmd.exe, you can just run this .bat to set the environment:

C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat

If you're trying to use the compilers from a makefile, Cygwin, MinGW, or something like that you need to set the environment variables manually. Assuming the compiler is installed in the default location, this should work for the Visual Studio 2008 compiler and the latest Windows SDK:

Add to PATH:

  • C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin
  • C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin
  • C:\Program Files\Microsoft Visual Studio 9.0\Common7\ID

Add to INCLUDE:

  • C:\Program Files\Microsoft SDKs\Windows\v6.1\Include
  • C:\Program Files\Microsoft Visual Studio 9.0\VC\include
  • C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\include

Add to LIB:

  • C:\Program Files\Microsoft SDKs\Windows\v6.1\Lib
  • C:\Program Files\Microsoft Visual Studio 9.0\VC\lib

These are the bare minimum, but should be enough for basic things. Study the vcvarsall.bat script to see what more you may want to set.

Ville Laurikari
A: 

The vcvarsall.bat batch file which is run by the Visual Studio command prompt is simply trying to keep your system environment variables and paths nice and clean (and is important if you have multiple versions of Visual Studio).

If you're happy limiting your setup to one version and having a long path and set of environment variables, transfer these settings (manually) to the System Environment Variables (My Computer|Properties --- or Win-Pause/Break).

I'd recommend against this though!

Ray Hayes
A: 

What the vcvars32 or vsvars32 batch files do is not rocket science. They simply set the PATH, INCLUDE, LIB, and possibly the LIBPATH environment variables to sensible defaults for the particular compiler version.

All you have to do is make sure that those things are set properly for your Ant or makefile (either before invoking them or within them).

For INCLUDE and LIB/LIBPATH an alternative to setting those items in environment variables is to pass those settings to to command line as explicit parameters.

Michael Burr
+3  A: 

Create your own batch file (say clenv.bat), and call that instead of cl:

@echo off
:: Load compilation environment
call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
:: Invoke compiler with any options passed to this batch file
"C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe" %*

clenv.bat can now be invoked just like cl.exe, except that it will first load the needed environment variables first.

Eclipse
A: 

The trick is to always use the correct vcvars batch file. IF you have just one version of VisualStudio installed, that's no big problem. If you're dealing with multiple versions like me, it becomes very easy to run a MSVC++ 14 build in a console that was set up with a MSVC++ 15 vcvars file. It might or might not work, but whatever you're getting will be different from what you'd be building from within VisualStudio.

We have dealt with that issue in terp by deriving the proper vcvars file from the chosen compiler and always setting up the environment internally to the tool invocation. This way, you always have the right vcvars file for the compiler you're using.

Just to reiterate: I highly recommend against trying to duplicate manually what the vcvars file does for you. You're bound to miss something or get it just right enough that it looks like it's working while actually doing something slightly different from what you wanted.