Cool great. BTW, a minor point or two, its better to set your paths by using the vcvars32.bat batch file, or to spawn a shell that is installed in the start menu that launches with it automatically. Also:

If you want to avoid pain, don't put spaces in the install paths of anything above. Manually specify every path into a usefully short high level name. Don't use the defaults!

Yes its possible to get everything working with spaces in the paths, but its much easier to avoid them in the first place. If you have problems with paths with spaces in them have a gander at junction to make a new directory that is an alias to the one with spaces in it. And then update your paths.

Returning to paths its well worth the time IMO to transer all of the paths normally loaded by vsvars32.bat or vcvars32.bat into your system enviornment. The easiest way to do this is to in an open shell

and then use the diff.txt to C&P the missing values into your system enviornment. This way if any of perls or cpans build enviornment spawns any of the c tools regardless of how or when you will always have the correct enviornment available.

Additionally you can find a free version of nmake.exe here unpack it and put it in your path somewhere (or put where it is in your path, *shrug*).

---
demerphq

First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

The set commands I listed above include the vcvars32.bat commands. But the vcvars32.bat does not set the environment for the SDK, only the Toolkit so it is not sufficienct by itself. You can save the set commands listed above as a batch file and run that *instead* of vcvars32.bat, or, as you point out, you can put these permanently in your enviornment (do as demerphq advices to make a diff, then, right click on my computer, select properties-advanced, select environment variables, find the PATH, LIB, and INCLUDE vars and set them with the output of the diff, or as I show above).

If you want to avoid pain, don't put spaces in the install paths

While I am sure you are right for most paths that have to do with perl, I do not believe that the spaces make any difference when they are meant (as the ones in the set commands above are) exclusively for use by windows. OTOH, the spaces bit me (and you helped me, thanks) when I tried to put the perl build (the one I unsuccessfully tried to build manually) in a directory with spaces. Your advice is probably safest as a general policy, but I really don't think it should or does make any difference for the compiler tools.

but I really don't think it should or does make any difference for the compiler tools.

My worry is that it may cause problems for such things as Inline.pm or ExtUtils::MakeMaker or various other cpan packages that involve compiling (some packages will try to compile little C snippets to see if your C compiler is available). Not all of these packages are smart enough to handle the various cross platform issues that come up, especially not spaces in the install paths.

I _strongly_ recommend that you install as much as possible in paths with no spaces for this reason. For instance I usually install Visual Studio dotNet in E:\dotNet and not in the MS recommended ditrectories. Ive never had a problem as long as I did this. However every time i forget about this (when I build a new machine for instance) and I always end up getting bitten and having to junction or reinstall. So while im sure a lot of stuff will work fine, i think the safest plan, and the lowest stress is to avoid them. After all its always when you have 6 minutes to get something done that a CPAN install blows up and starts wining about not being able to find the compiler that is most definately there. :-)

OTOH, im not going to get too strung out about it, after all Ive already installed them in directories without spaces in their names so it wont be me getting bitten. :-p

---
demerphq

First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

My worry is that it may cause problems for such things as Inline.pm or ExtUtils::MakeMaker or various other cpan packages that involve compiling

Aha! Excellent point. I retract my caveat to your advice. OTOH, I beleive that the better fix is for those modules to behave properly given the known fact that windows directory names can contain spaces. It should not be up to perl users to fiddle with these details, perl and perl modules should handle them.