Windows export: 'cl.exe' is not recognized as an internal or external command,

[posted as a new topic for visibility from here ]

Building for windows on openfl 4.3.1 produces:

‘cl.exe’ is not recognized as an internal or external command,
operable program or batch file.

Seems possibly connected to this issue:

I tried re-installing via
openfl setup windows

but still the same issue. there are some solutions presented here:

but I’m apprehensive about trying solutions for a different dev environment.

this work for me:

haxelib set hxcpp 3.2.102

Setting hxcpp to 3.2.102 I now receive:

Error: Could not find include file "C:/HaxeToolkit/haxe/lib/hxcpp/3,2,102/src/hx/libs/regexp/Build.xml"

Not sure if this is better or worse

Try a clean compilation

My build command is automated through FlashDevelop. How can I append -clean to it?

You can append “-clean” by typing it into the platform text box, after “windows.”

If it’s more convenient, you can simulate a clean build by deleting your bin or Export folder, then building.

After I perform a clean build I encounter the same error, but it now also adds:

You must have a "project.xml" file or specify another valid project file when using the 'display' command

Newer versions of hxcpp definitely have that Build.xml file, so you might as well go back to what you were using.

You have Visual Studio installed, right? Find the folder where it’s installed, then look for a “Common7” folder (or, failing that, another “Common” folder), with a “Tools” folder inside that. Inside Common7/Tools, you should find a file named vsvars32.bat.

If you don’t find this file, then you need to reinstall or update Visual Studio’s tools (either download Visual Studio Express, or Visual Studio itself, but in the latter case you’ll have to check the right checkbox).

If you do find this file, then the problem is that hxcpp can’t find it. When searching, hxcpp checks a bunch of different environment variables, in order from most recent to least recent. Normally, Visual Studio’s installer will set the appropriate variable for you, but you can also do it manually.

Let’s say you have Visual Studio 11. Then the variable you want to set is VS110COMNTOOLS (“Visual Studio 11 common tools”), and you want to set it to “C:\Program Files (x86)\Visual Studio 11.0\Common7\Tools.” To do this:

> setx VS110COMNTOOLS "C:\Program Files (x86)\Visual Studio 11.0\Common7\Tools"

Or if you want to set it for all users, launch Command Prompt as an administrator, and do this:

> setx /M VS110COMNTOOLS "C:\Program Files (x86)\Visual Studio 11.0\Common7\Tools"

(Edit: it turns out you have to set it for all users.)

Once you do this, you may need to restart FlashDevelop or your computer.

This won’t affect compilation, but it’s certainly annoying. Open up project properties in FlashDevelop, and make sure the configuration file is correct.

Verified the existence of vsvars32.bat. It is located at:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat

I ran the command

setx VS10COMNTOOLS "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools"

it gave me:

SUCCESS: Specified value was saved

I restarted my computer. Changed hxcpp back to 3.3.49. Tried a clean windows build. Issue persists :frowning:

Oops! Looks like I forgot a zero.

Sorry about that!

By the way, I just remembered that you don’t have to use the command line. If you use the GUI, you can edit the name of a variable. This will save you the trouble of deleting one variable and making another.

So I made another call to setx, specifying VS100COMNTOOLS this time and not VS10COMNTOOLS. Restarted. Same issue. Checked my environment variables. Saw this:

Feel like I’m going crazy, lol.

Ok, here’s the next test, to narrow down where the problem is.

> where cl.exe
> "%VS120COMNTOOLS%\vsvars32.bat"
> where cl.exe

The first command should print “Could not find files for the given pattern(s).” The second command should print nothing at all. The third command should print a path.

If this works, copy down the path, then restart command prompt and try this:

> "C:/HaxeToolkit/haxe/lib/hxcpp/3,3,49/toolchain/msvc-setup.bat"

Running this will not give you access to cl.exe, thanks to the first line of mvsc-setup.bat. However, that’s ok. After running that batch file, hxcpp reads the output and copies the path variable (among others).

So what you want to do is take a look through all the lines that get printed when you run mvsc-setup.bat, and make sure that the line starting with “Path=” contains the path you copied down. (It’s fine if the capitalization is different.)

Following your steps, the third command printed this path:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe

upon running mvsc-setup.bat, I confirmed that the above path was NOT in the list of printed paths. On a whim I tried running

> setx /M VS100COMNTOOLS "C:\Program Files (x86)\Visual Studio 10.0\Common7\Tools"

again, since I had not done so as administrator before. After running mvsc-setup again, I could confirm that new paths were added to the output, however the closest path I could find there was:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN;

and not

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe

Restarted computer, issue persists.
…are we getting closer?

This is correct. Since this folder is in your path, hxcpp will look there for cl.exe. Have you tried compiling?

Sorry, I guess I misspoke when I said it had to match exactly. (And even emphasized the word “exactly” for effect.) The path, minus “\cl.exe,” is what has to match.

Also, good to know that you have to set it for all users. I’ll update my previous post in case anyone visits this thread later.

So erm, the paths seem to be updated correctly… what else could be causing this? I’ll re-post my full error message in case something changed that I didn’t realize:

'cl.exe' is not recognized as an internal or external command,
operable program or batch file.
Error: error running cl.exe -Iinclude -nologo -DHX_WINDOWS -D_USING_V140_SDK71_ -GR -O2 -Oy- -c -EHs -GS- -arch:SSE -IC:/HaxeToolkit/haxe/lib/hxcpp/3,3,49/include -DHXCPP_VISIT_ALLOCS -DHXCPP_API_LEVEL=330 -D_CRT_SECURE_NO_DEPRECATE -D_ALLOW_MSC_VER_MISMATCH -D_ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH -wd4996 -Ie:/VS8//PlatformSDK/Include -MT -Ychxcpp.h -Yllink274eaa16c89e1335185d5725af799279 J:/HAXE/SodaDungeon/bin/windows/cpp/release/obj/obj/msvc-ncxp/__pch/haxe/hxcpp.cpp /FpJ:/HAXE/SodaDungeon/bin/windows/cpp/release/obj/obj/msvc-ncxp/__pch/haxe/hxcpp.pch -FoJ:/HAXE/SodaDungeon/bin/windows/cpp/release/obj/obj/msvc-ncxp/__pch/haxe/hxcpp.obj
Build halted with errors.

Wait a minute…

HXCPP only sets this if you have Visual Studio 14. Or at least, if VS140COMNTOOLS is defined.

What happens when you run this?

> "%VS140COMNTOOLS%\vsvars32.bat"
> where cl.exe

What happens when you run this?

After the first command, nothing. After the second:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe

I do have VS 2014 installed, as I see similar output in my mvsc-setup path:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\;
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN;
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools;

But I’ve been assuming that VS 10/14 stay isolated from each other, and that hxcpp requires VS 2010 since it tries to install that after running openfl setup windows

Well, that’s unexpected. Shouldn’t it have added its own path? (I don’t actually know how vsvars32.bat works, and I don’t have time to dig into it.)

That’s closer to what I was expecting. Did you check in Microsoft Visual Studio 14.0\vc\bin for cl.exe?

No, that’s just what OpenFL suggests. hxcpp seems to support everything up to 14; otherwise msvc-setup.bat wouldn’t check for 14.

That said, the solution might be to go with 10, if 14 is missing cl.exe. Do this by deleting VS140COMNTOOLS from your environment variables, or by setting HXCPP_MSVC to the value of VS100COMNTOOLS.

Welp, there we go. VS 2014 does not come with cl.exe by default. It appears it can be manually installed, but I only see official downloads for VS 2015. So like you suggested I just created a new system environment variable called ‘HXCP_MSVC’ and set it equal to

C:\Program Files (x86)\Visual Studio 10.0\Common7\Tools

game seems to run and export just fine now, though I’ve noticed that the glow filters I use on text aren’t rendering like they should be. will do some testing tomorrow and see if I can figure that out.

In the meantime, thank you!

You’re welcome!

By the way, I suggest clicking the checkbox on your post so that future readers can easily find the solution.