NetBeans 6.1 w/CND pack mishandles paths with spaces in Windows (at least) because it either fails to escape them or
quote the whole path. In particular, I have GFortran installed into C:\Program Files\gfortran, so all my tools are in
the bin subdirectory of that folder. Trying to build the project reports:
------ Output - FTest (Build)
Running "C:\Program Files\gfortran\bin\make.exe -f Makefile CONF=debug" in "C:\Users\javier\Documents\NetBeansProjects\FTest
"C:\Programª is not recognized as an internal or external
command, application or batch file
Build failed. Exit value 1
------
Clearly NetBeans is running the make.exe without noticing that it should either quote it or escape the space in "Program
Files" - I don't know cmd.exe very well so escaping might not be possible, but the command line would have failed under
MSys, so quoting would be the most sensible approach.

I'll look at this next week. Bear in mind that Unixish tools like GNU make, gcc, and g++
do have limitations with respect to spaces in paths. This one might be OK, but no guarantees.
Although I'll look at it next week, its not critical enough to consider for NB 6.5 (which is
very close to code freeze for FCS).

I don't really know how strict the freeze policies are in the NetBeans project, but this change might consist of just
looking for the line of code that invokes external commands and make it quote them. If it works, then life is beautiful;
if it doesn't, then it is reverted and the issue set for re-examination after the release. Would that be acceptable? I
could even propose the patch myself if it's OK and people here are too busy with the release...

i can see that MakeArtifacts' getBuildCommand and getCleanCommand prevented us from having spaces in tool path,
but now makeFlags are always empty (see usages of the above methods), so we can provide tool path to the execution.

Make can be fixed if IDE provides environment variable.
For example: this is work right on unix:
#/opt/SUNWspro\ old/prod/bin/dmake MAKE="/opt/SUNWspro\ old/prod/bin/dmake"
But exist a couple other places with bad escaping.

A lot has changed since this bug was filed, but the bug is still there. I made a fix in make project how it setups the make command and it should be correct now. The ProjectAction now ends up in RemoteBuildAction Handler and I think it is not handling the space correctly in the exe command. Will reassign to Vladimir K. for further evaluation. I think the fix is somewhere in RemoteBuildAction where it needs to either escape the space or quote the path.