Cl.exe Options

[Andree Vandestreek]

Am trying to use the Visual Studio Express 2010 C++ compiler without using the IDE. I found cl.exe in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin. However am having a few difficulties. Firstly it gave me a warning pop up when i type cl saying 'Program cannot start because mspdb100.dll is missing from your computer.'

Any idea how to solve this so i can compile? Also how would i set up the path so i can just type 'cl main.cpp' etc, from within a solution folder that does not contain cl.exe. At the moment i have to be inside bin folder. Thanks.

From there, name it cl.bat. Put this in a folder somewhere, and add the path to that folder to your PATH environment variable, making sure it comes before the path to cl.exe, so that this cl.bat is executed whenever you type cl instead of cl.exe

This is a quite simple and strait forward task. Firstly add the compiler path to system path.:C:\Program Files\Microsoft Visual Studio 10.0\VC\bin; Next, open command prompt and change directory to your source folder; Then execute the vcvars32.bat file to setup the environment for using vc++ on x86; After this, you can now type cl to compile your program

I have multiple versions of VS installed; I create a little .BAT file for each version, placed somewhere in the path, that calls the relevant "vcvarsall.bat". e.g. "vc9.bat" calls vcvarsall.bat for VS2008, while "vc10.bat" calls vcvarsall.bat for VS2010. I can open a normal command window as usual, type "vc9", and presto, that command window is ready to compile etc using VS2008.

Or, better yet, add it to the project's settings in the .vcxproj.
To specify the 64-bit version of the compiler and tools, add the following property group element to the Myproject.vcxproj project file after the Microsoft.Cpp.default.props element:

I have a project that I converted from a makefile that has a source file that expects the command line options from the compiler. For example for when the project was built with gcc if you did program --help it would spit out the gcc command line used to compile the program.

How can I do the same thing in Visual Studio, so that it spits out the cl command line used to compile the program? Basically I want to hit F7 (to build solution) and have the whole thing automated. I can't find a macro for it. Thanks

edit; I mean programatically, so for example I want when I run the program for its output to contain the cl.exe command string that is used. You can see the command line at Configuration Properties > C/C++ > Command Line > All Options but I can't find a macro for it or some way to encapsulate it in a file.

Since VS switched the underlying build system to MsBuild the command line as shown in that dialog is created programatically within VS only. It might not even be the exact command line passed to cl: MsBuild itself invokes CL via a task and as such there is no direct link with what is shown in VS nor is there a way to get the command line out of it.

Anyway, there is no such thing as the command line since each source file might have different options. Furthermore I doubt you want the full commandline including the absolute include paths etc. Nobody is interested in that. Now if you make clever use of the macros from -us/library/b0084kay.aspx you can sort of recreate the command line yourself since most options are there:

Using Override compiler solution, I changed ClCompile ToolExe to custom mycl.bat script and this script received an argument which was @tmp-1234xxx.rsp file. This rsp file contained whole command line except cl.exe path, something like -

Then after making desired changes in the rsp file by calling a separate bash script which were very minor for me, I called cl.exe with contents of my rsp file. So, whenever user hits the build button, this script executes.

The problem I faced is Visual Studio uses tlogs written by CL Task to check while file needs to to be rebuilt on incremental build and my target's tlogs files were not enough. There were tlogs of every command in batch and bash scripts but not for whole target. So, it was building whole thing on incremental builds also.

Furthermore, cl.exe supports P1689R5 with the /scanDependencies switch, whereas the Clang/LLVM ecosystem uses a different binary altogether, with clang-scan-deps.exe. How is this intended to be handled with clang-cl.exe?

If I use -fmodule-file=, I cannot link, and the linker complains that it cannot find hello(). If I use fprebuilt-module-path and supply the precompiled module file, the compiler then complains that module Hello cannot be found:

Each option begins with a switch character, which can be either a forward slash or hyphen. The standard practice in these notes (as also of the product documentation and of CL itself both for command-line errors and warnings and in the summary produced by the /help option) is to use the forward slash in all references to CL options, leaving it as understood that the hyphen is equivalent unless otherwise stated.

Some CL options that begin with the same letter or letters after the switch character can be combined into one command-line token, with the switch character and common letters given just the once. For example, the sequence of options/Ob2 /Og /Oi /Ot /Oy can be compressed to/Ob2gity. Such combined options are just a convenient shorthand. CL unpicks the combination to recover the individual options, which are thereafter treated as if they actually had been given individually. Only individual options are discussed henceforth. An alphabetical list ofindividual options is given separately and leads to notes for each option. Those notes assume familiarity with the general notes given here.

Some options have a negation formed by appending a hyphen. Typically, the ordinary option enables some feature and the negation disables it. For example, /GR directs the compiler to emit Run-Time Type Information and /GR- directs it not to. Not all these negations are noted in the product documentation.

A handful of options allow or require a keyword, which is to follow immediately after a colon. Indeed, the only examples are/clr and/Zc. The first may be given alone or as /clr:noAssembly (or with a negation, albeit undocumented). The second is invalid without a keyword (which may be eitherforScope or wchar_t).

Though these notes set out to treat negations and keywords as variations of the underlying option, presuming this to simplify the concept, it is as well to bear in mind that the implementation actually parses them as separate options. Thus, a /clr or /Zc with a colon and an unrecognised keyword is rejected as an unknown option (with warningD4002), not as an incorrect formulation of a recognised option.

In general, CL options and their keywords are case-sensitive. For example,/GR and /Gr are very different options (one to enable Run-Time Type Information, as noted above, the other to set a default calling convention).

Exceptions are very few. True case-insensitivity applies to just one option, namely /clr (including if given as a negation or with a keyword). One other option, namely /help, is partly case-insensitive in that it is recognised equivalently whether all in lower case or all in upper case.

Some options accept or require an argument. For all except/D, /link, /Tc, /To, /Tp and /U, the parsing of one or more command-line tokens into an option and its argument has a common implementation whose details are given here so that the syntax notes for each option need merely state which case applies.

If an option is not the whole of its command-line token, then the argument can only be the remainder of that same token. Note that the argument begins immediately after the defining characters of the option, including if this means that the argument starts with white space. For example, in the command

For some options, if the option is the whole of its command-line token, then the argument may instead be the whole of the next token. The option then consists of two tokens. For example, in the command

If the command-line token that starts the option continues with a switch character, then the option is deemed to have no argument. The remainder of the token, from the switch character onwards, is ignored without complaint, and no argument is collected from the next token. For example, in the command

the /FI has no argument, the /anything in the same command-line token simply never gets interpreted, and the whatever that is the next token is not considered as a possible extension of the/FI option.

If the token that starts the option has no continuation and the option is one of those that can take its argument from the next token but this next token starts with a switch character, then the next token is not deemed part of the option and the option again has no argument. For example, in the command

Given that an argument is recognised, it is subject to a maximum length, presently 1024 characters. Exceeding this maximum is an error (D2038). Since this applies so generally, it is not mentioned in the syntax notes for particular options. Indeed, the error is so self-explanatory that the product documentation seems not to bother mentioning it anywhere.

The standard notation for a numerical argument is decimal. It allows for any amount of white space at the start of the argument, including none, and then for a plus or minus sign, before requiring one or more decimal digits. The number that is formed from as many decimal digits as follow is evaluated as an unsigned 32-bit integer. If the number is too large for 32 bits, it is coerced to 0xFFFFFFFF without complaint. The number becomes the numerical value of the argument, except that if a minus sign preceded the number, the value is negated. (A numerical argument that is too large but negative therefore evaluates to 1.)

A handful of options (just /F,/Gs, /H and/nl) permit an additional notation in which a prefix sets the base as octal, decimal or hexadecimal. The prefix is0x for hexadecimal, 0d or 0t for decimal and 0 alone for octal. The prefix is case-insensitive, as are hexadecimal digits. The prefix is recognised only at the very start of the argument, not after white space. The decimal prefix is in effect discarded, so that the remainder of the argument is interpreted according to the standard notation (with its tolerance of white space, except that this must now follow the prefix rather than begin the argument). The octal and hexadecimal cases do not allow for white space or a sign, but require that the prefix be followed immediately by one or more characters that are valid digits for the selected base. The number formed from these digits is evaluated as an unsigned 32-bit integer. If the number is too large for 32 bits, it is coerced to 0xFFFFFFFF without complaint. The number becomes the numerical value of the argument.

c80f0f1006