Windows Dev and Dashboard Prompt

First set up a cmd file (a batch file with a *.cmd extension) whose sole purpose is to set environment variables.

Mine, called DashboardEnv.cmd, looks like this on one of the machines where I have Visual Studio 2010 Express Edition installed:

    @call "%VS100COMNTOOLS%\vsvars32.bat"
    @set PATH=C:\Program Files\Git\bin;%PATH%
    @set PATH=%USERPROFILE%\DevBox\cmake-2.8.10.2\bin;%PATH%
    @set PATH=C:\Python27;%PATH%
    @set PATH=C:\Qt\4.8.4-vs10\bin;%PATH%
    @set PATH=C:\dev\tools\bin;%PATH%

As you can see by inspecting that file, it sets up the environment just like a Visual Studio command prompt, and then adds a bunch of useful stuff to the PATH environment variable: git, cmake, python, qmake, ninja and jom, to name a few. I have ninja and jom in the C:\dev\tools\bin directory -- they could be anywhere, you just have to add the right directory to the PATH here in this script.

Next, set up a cmd file in the same directory as the environment batch file to display a "developer cmd prompt."

Mine, called DashboardPrompt.cmd, looks like this:

    @call "%~dp0DashboardEnv.cmd"

    @title Dashboard Prompt

    @echo.
    @echo Environment set by "%~f0"
    @echo.

    @call "%COMSPEC%"

If you prefer the "git bash" prompt to the raw Windows cmd prompt, you can change the call COMSPEC line to:

    @call "C:\Program Files\Git\bin\sh.exe" --login -i
After you have both of those setup, double click the prompt cmd file to test it out. Then you can create a shortcut to the prompt cmd file, put it on your desktop, or whereever you like, and then just double-click the shortcut to get a new instance of your customized developer prompt.

Some things I do to make the command prompt itself slightly less intolerable:

• edit the command prompt window properties: with the window open, click on the icon in the top left corner, and choose "Properties" from the menu
• modify the properties of the window to allow "select-and-Enter-key to copy, right-click to paste" behavior by choosing the "QuickEdit Mode" checkbox
• set the screen buffer height (number of scroll back lines) to 9999, the max allowed
• set the window size to something larger so you can see more text at once (120 by 40-50 is nice depending on your usual screen)
• set the font to Lucida Console, and choose a font size large enough to read
• if prompted, check "modify the shortcut that started this prompt" on the way out

Now that you're all set up for an interactive prompt with the right environment... here's the reason why separating it into two scripts is good for you. You can easily run any other script with the very same environment by adding one line at the top of it:

    @call "%~dp0DashboardEnv.cmd"

The %~dp0 there means "drive letter (d) and full path of containing directory (p) without any double quotes (~) of this script file (arg 0) including the trailing '\' character (implicit in p)" -- so if you write a script that references another script in the same directory, using %~dp0 is a reliable way to reference it, regardless of how the batch file was invoked. See the output of "help for" in a Windows command prompt for all the gory details about possible letter codes you can use in such constructs.

So: to run dashboards or other automated builds with the same environment that you use for interactive development, you can write a script that uses your Env.cmd file.

Mine, called RunDashboards.cmd, looks like this:

    @call "%~dp0DashboardEnv.cmd"

    @title Run Dashboards

    @echo.
    @echo Running script "%~f0"
    @echo.  started on %DATE% at %TIME%
    @echo.

    @echo.
    @echo Updating VTKLargeData...
    @cd "C:\dev\My Tests\VTKLargeData"
    @git pull

    @echo.
    @echo Updating VTKData...
    @cd "C:\dev\My Tests\VTKData"
    @git pull

    @echo.
    @echo Running VTK Release dashboard...
    @cd "C:\dev\My Tests\VTK"
    @ctest -S C:\dev\EasyDashboardScripts\EasyDashboard.cmake,ninja-Nightly-Release

    @echo.
    @echo Running VTK Debug dashboard...
    @cd "C:\dev\My Tests\VTK"
    @ctest -S C:\dev\EasyDashboardScripts\EasyDashboard.cmake,ninja-Nightly-Debug

One nice thing about guaranteeing the right environment is set for running a script like this is being able to just use "git" and "ctest" in the script itself.

Obviously, you'll need to adjust path values according to tool installations on different machines.

For more details on setting up to run dashboards on Windows, see this page over on the CMake blog. (Also published on the Kitware blog.)

Good luck -- tweet me @DLRdave or ping me on G+ if you use this technique.

"Fun" With Batch Files

Here's how to compute the root Program Files directory of the Visual Studio 2008 installation from the VS90COMNTOOLS environment variable... (for example...) Obviously: same technique may apply to other env vars and other programs.

The Line of Code
In a batch file:
for /f "usebackq delims=" %%d in (`echo "%VS90COMNTOOLS%\..\.."`) do set VS_ROOT_DIR=%%~fd

Directly in a command prompt:
for /f "usebackq delims=" %d in (`echo "%VS90COMNTOOLS%\..\.."`) do set VS_ROOT_DIR=%~fd

The only difference between the two is the doubling up of the "%%d" percents when referencing for loop variables. Don't ask why, just learn: that's the way it is. Actually, if you want to ask why and then go figure out the answer... that would be a good blog post for you to write.

The Dissection
On my machine, the command...
echo "%VS90COMNTOOLS%\..\.."

...produces:
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\\..\.."

Nice. Accurate and all, but look at all the ugliness we've produced. Doubled up backslashes, enclosing double quotes, ..s, not to mention the length.

So. That fancy "for /f" line. Let's clean up that output to remove the ugliness.

Using "for /f" with the "usebackq" option allows you to put a command inside backticks, as in `echo something`, and capture the output of that command in the for loop variable. In this dead simple example, the for loop would iterate exactly once, and the value "something" would be in the loop variable.

Using the "delims=" option allows you to split the output by delimiter characters. When you say "delims=" with the equal sign right up against the closing double quote, that means: no delimiter characters, give me the full output all at once. Much different result than "delims= " with a space in between... that one loops over the output separating by space characters, giving multiple for loop iterations based on how many spaces are in the output. You could also say "delims=\" to split at the path separator character, or "delims= \/:" to split at common date time separators.

Now that usebackq and delims are well understood, or at least explained, how does that help us get rid of the ugliness? Well... it's mostly the magical "%~fd" at the very end of our friendly line of code that makes the universe beautiful again. The usebackq/delims pain we went through was really just a way to get the string we want into a for loop variable so we can take advantage of for loop variable expansion modifiers.

for /f "usebackq delims=" %d in (`echo "%VS90COMNTOOLS%\..\.."`) do set VS_ROOT_DIR=%~fd

The "%~fd" says this: give me the value of the loop variable %d, and while you're at it, remove any enclosing double quotes (~), and resolve it to a full path, assuming the variable represents a file or directory name (f).

The net effect of all this is that our line of code...
for /f "usebackq delims=" %d in (`echo "%VS90COMNTOOLS%\..\.."`) do set VS_ROOT_DIR=%~fd

Finally, in the end, simply evaluates to the line of code we wanted to write in the first place, but without hard coding a machine specific path name in a batch file:
set VS_ROOT_DIR=C:\Program Files (x86)\Microsoft Visual Studio 9.0

Type "help for" in a Windows command prompt for more of the gory, sickening details regarding loop variable expansion.

And help keep the universe beautiful. Even if you still have to write batch files once in a while.

Must Have Windows Software

Whenever I get a new computer running Windows, like I am today at work, the first thing I download and install on it is Firefox. Then, using Firefox, I have to download and install the following shet of shtuff to make it programmer friendly. This is my way of avoiding being ripped to shreds by the open source sharks for actually having paid money for a computer running Windows... Actually, to avoid that completely, I'd have to install emacs or gvim, too. But I won't do that until somebody else has to use the computer and looks like he's floundering without it.

Must haves:

• Process Explorer
• notepad++
• PuTTY
• VNC
• CMake
• TortoiseCVS, including CVSNT command line client
• TortoiseSVN
• SVN command line client, usually the CollabNet one
• Git, the msys one

And then, the hard core development tool:

• Microsoft Visual Studio, whatever version(s) necessary to do my job...
  

And then, as necessary, but only as necessary:

• xampp, for a localhost web server
  
• NSIS, the installer builder
• doxygen
• graphviz
  
• ActiveState Python
• ActiveState Perl
• ActiveState Tcl
  
• MagicDisc, or similar ISO image mounting utility

Details:

notepad++ -- like notepad, but seriously OD'd on steroids: all kinds of built-in language syntax highlighting

VNC -- if I'm lucky, one that includes a free server so I can access the Windows box from other computers... if not, then at least RealVNC client so I can access other machines

Anybody out there have any other "must haves" that belong on a Windows box?

Sick of these C# warnings? Here's how to eliminate them...

8>warning CS1668: Invalid search path 'c:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\lib\i386' specified in 'LIB environment variable' -- 'The system cannot find the path specified. '

8>warning CS1668: Invalid search path 'C:\Program Files\Microsoft Visual Studio 9.0\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified. '

The Visual Studio installer does a mysterious thing here.

The entries found at "Tools > Options > Projects and Solutions > VC++ Directories" point to some non-existing directories. But the entries are used to populate the LIB environment variable when building projects inside the IDE. So... if you build a C# project in the IDE, you get this warning about invalid search paths in the LIB environment variable.

Now, I'll give them the benefit of the doubt: maybe some installations of Visual Studio *do* produce these directories. However, this warning has been occurring all through the VS 2005 and 2008 series and I have always encountered it on every machine I've ever built a C# project on. Of course, there's one thing unusual about the way I typically build C# code that I forgot to mention: I usually build C# code with custom commands that drive the C# compiler directly from the build context of a C++ project. So I understand if Microsoft doesn't have a test that tries this scenario out. "Why would anybody do that, anyway?" :-)

The fact remains: those settings cause these warnings, and the installer has never installed those directories for me. I'm calling it a bug.

The way to get rid of this warning is to edit the entries to remove the ones that point to non-existent directories. The trick is figuring out which ones they are.

This one: "c:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\lib\i386" comes from the entry for "Win32" / "Library files":

$(VCInstallDir)atlmfc\lib\i386

VCInstallDir evaluates to "c:\Program Files\Microsoft Visual Studio 9.0\VC\"

This one: "C:\Program Files\Microsoft Visual Studio 9.0\lib" comes from the entry for "Win32" / "Library files":

$(VSInstallDir)lib

VSInstallDir evaluates to "C:\Program Files\Microsoft Visual Studio 9.0\"

Click on each of those in the Tools > Options dialog and delete them.

Voila. Warning gone.