Building LIBSVM on WIndows - libsvm

Question

I am trying to do a build from the command line for a windows PC of the version of LIBSVM 3.17 modified to allow weighted instances
(from http://www.csie.ntu.edu.tw/~cjlin/libsvmtools/#weights_for_data_instances ).
I am using the executable tools from Microsoft Visual Studio 2010, but am getting an error I don't understand. Microsoft's documentation of the error gets me no further. Can anyone point me in a useful direction, or has anyone managed to compile this package for Windows?
I am running at the command line:
nmake -f Makefile.win
and getting an error:
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0 \VC\bin\cl.exe"' : return code '0xc0000135' Stop.
The full makefile is:
**CXX = cl.exe
CFLAGS = -nologo -O2 -EHsc -I. -D __WIN32__ -D _CRT_SECURE_NO_DEPRECATE
TARGET = windows
all: $(TARGET)\svm-train.exe $(TARGET)\svm-predict.exe $(TARGET)\svm-scale.exe $(TARGET)\svm-toy.exe lib
$(TARGET)\svm-predict.exe: svm.h svm-predict.c svm.obj
$(CXX) $(CFLAGS) svm-predict.c svm.obj -Fe$(TARGET)\svm-predict.exe
$(TARGET)\svm-train.exe: svm.h svm-train.c svm.obj
$(CXX) $(CFLAGS) svm-train.c svm.obj -Fe$(TARGET)\svm-train.exe
$(TARGET)\svm-scale.exe: svm.h svm-scale.c
$(CXX) $(CFLAGS) svm-scale.c -Fe$(TARGET)\svm-scale.exe
$(TARGET)\svm-toy.exe: svm.h svm.obj svm-toy\windows\svm-toy.cpp
$(CXX) $(CFLAGS) svm-toy\windows\svm-toy.cpp svm.obj user32.lib gdi32.lib comdlg32.lib -Fe$(TARGET)\svm-toy.exe
svm.obj: svm.cpp svm.h
$(CXX) $(CFLAGS) -c svm.cpp
lib: svm.cpp svm.h svm.def
$(CXX) $(CFLAGS) -LD svm.cpp -Fe$(TARGET)\libsvm -link -DEF:svm.def
clean:
-erase /Q *.obj $(TARGET)\**

Answer 1

I would suggest you to compile it from visual studio directly since is easier, but if you still want to do it from the command like this link might help:
NMAKE : fatal error U1077: return code '0xc0000135'
Apparently the problem is that NMake couldn't find the compiler's path.

Answer 2

I discovered (by guessing) that I needed to manually create a directory called "windows" where the executables were produced. Not entirely sure why this was necessary, but it did the job, and I still can't see a way to do it without doing so.